On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <[email protected]> wrote:
> Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu: > > > Now, the privileged process wants to launch a sub-process. How will the > > > sub- process connect to the compositor? Remember: WAYLAND_SOCKET > contains > > > a file descriptor number that isn't available to the child process. > > > > Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using > fcntl() to > > set the socket's fd to CLOEXEC? > > Setting the socket to O_CLOEXEC is mandatory after you start using it. Two > processes cannot write to the same streaming socket file descriptor at the > same > time. You might be able to do this with a datagram socket, but that's not > the > case here. > > > It is true that multiple process could end up with the same connection > and > > I didn't think about that. The problem is the same if an application > > connects > > to the compositor by itself and then forks. Not sure how the compositor > > could detect that :s > > It can't. It will get very confused because two applications with > independent > states will start stepping on each other's toes. The best outcome of this > would be if the compositor detected a problem early on and cut the > connection > to both. > > The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET > environment variable after getting the file descriptor number and it must > set > O_CLOEXEC. The socket is not available to child processes. > It already does both of these: http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763 > > But then the question returns: how do child processes connect to the > compositor, if the environment variable was cleared? How do they find the > compositor? > > Solutions: > > 1) the compositor MUST have a well-known socket name > => not an option, since we want to have multiple concurrent compositors > > 2) wl_display_connect() doesn't clear the environment, but resets it to the > actual socket name. It needs to get the socket name from somewhere. > => problem: if it's getting the name from the compositor, this may take a > few roundtrips and the process may have decided to start the child > process > > 3) use a different environment variable. One variable contains the > traditional > socket path and the other contains the file descriptor. The latter > overrides > the former. > This is what we are doing right now. The WAYLAND_DISPLAY environment variable contains the name of a socket that can be found in XDG_RUNTIME_DIR. The WAYLAND_SOCKET environment variable (if it exists) contains a file descriptor that a single client can use to connect to the compositor. Inside wl_display_connect, we clear WAYLAND_SOCKET but not WAYLAND_DISPLAY. If both are present, the client connects directly and is then free to spawn other clients which will connect via WAYLAND_DISPLAY. However, those other clients will not have the same priviledged status because they didn't use the direct connection. This is the way Weston's desktop-shell panel spawns things right now. > 4) store both settings in WAYLAND_SOCKET. D-Bus does that: > DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in > order. > That's an interesting idea. Not sure what benefit it would have for Wayland right now though. Hope that helps, --Jason Ekstrand
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
