<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <span dir="ltr"><<a href="mailto:thiago@kde.org" target="_blank">thiago@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Em qui 20 fev 2014, ās 21:31:59, Martin Peres escreveu:<br>
<div class="">> > Now, the privileged process wants to launch a sub-process. How will the<br>
> > sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains<br>
> > a file descriptor number that isn't available to the child process.<br>
><br>
> Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using fcntl() to<br>
> set the socket's fd to CLOEXEC?<br>
<br>
</div>Setting the socket to O_CLOEXEC is mandatory after you start using it. Two<br>
processes cannot write to the same streaming socket file descriptor at the same<br>
time. You might be able to do this with a datagram socket, but that's not the<br>
case here.<br>
<div class=""><br>
> It is true that multiple process could end up with the same connection and<br>
> I didn't think about that. The problem is the same if an application<br>
> connects<br>
> to the compositor by itself and then forks. Not sure how the compositor<br>
> could detect that :s<br>
<br>
</div>It can't. It will get very confused because two applications with independent<br>
states will start stepping on each other's toes. The best outcome of this<br>
would be if the compositor detected a problem early on and cut the connection<br>
to both.<br>
<br>
The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET<br>
environment variable after getting the file descriptor number and it must set<br>
O_CLOEXEC. The socket is not available to child processes.<br></blockquote><div><br></div><div>It already does both of these: <a href="http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763">http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763</a><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But then the question returns: how do child processes connect to the<br>
compositor, if the environment variable was cleared? How do they find the<br>
compositor?<br>
<br>
Solutions:<br>
<br>
1) the compositor MUST have a well-known socket name<br>
=> not an option, since we want to have multiple concurrent compositors<br>
<br>
2) wl_display_connect() doesn't clear the environment, but resets it to the<br>
actual socket name. It needs to get the socket name from somewhere.<br>
=> problem: if it's getting the name from the compositor, this may take a<br>
few roundtrips and the process may have decided to start the child process<br>
<br>
3) use a different environment variable. One variable contains the traditional<br>
socket path and the other contains the file descriptor. The latter overrides<br>
the former.<br></blockquote><div><br></div><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4) store both settings in WAYLAND_SOCKET. D-Bus does that:<br>
DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in<br>
order.<br></blockquote><div><br></div><div>That's an interesting idea. Not sure what benefit it would have for Wayland right now though. <br></div><div><br></div><div>Hope that helps,<br></div><div>--Jason Ekstrand<br>
</div></div><br></div></div>