<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 5, 2014 at 2:23 PM, Karsten Otto <span dir="ltr"><<a href="mailto:karsten.otto@posteo.de" target="_blank">karsten.otto@posteo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 29.09.2014 um 06:31 schrieb Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>>:<br>
<span class=""><br>
><br>
> On Sep 28, 2014 11:49 AM, "Karsten Otto" <<a href="mailto:karsten.otto@posteo.de">karsten.otto@posteo.de</a>> wrote:<br>
> ><br>
> > From: Philip Withnall <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>><br>
> ><br>
> > This happens if the socket has been gracefully closed.<br>
> ><br>
> > [KAO: It prevents a potential infinite loop when using a different<br>
> > event handling mechanism than epoll, if said mechanism cannot<br>
> > distinguish EOF from regular read (e.g. select).]<br>
> > ---<br>
> > src/wayland-server.c | 2 +-<br>
> > 1 file changed, 1 insertion(+), 1 deletion(-)<br>
> ><br>
> > diff --git a/src/wayland-server.c b/src/wayland-server.c<br>
> > index 674aeca..85741cb 100644<br>
> > --- a/src/wayland-server.c<br>
> > +++ b/src/wayland-server.c<br>
> > @@ -260,7 +260,7 @@ wl_client_connection_data(int fd, uint32_t mask, void *data)<br>
> > len = 0;<br>
> > if (mask & WL_EVENT_READABLE) {<br>
> > len = wl_connection_read(connection);<br>
> > - if (len < 0 && errno != EAGAIN) {<br>
> > + if (len == 0 || (len < 0 && errno != EAGAIN)) {<br>
> > wl_client_destroy(client);<br>
> > return 1;<br>
><br>
> It seems to me as if we should push this up the pipe to wl_connection_read so we fix it server-side too.<br>
><br>
</span>What do you mean? Calling wl_client_destroy within wl_client_read? Or making sure the connection is properly disposed of in both client and server code?<br>
<br>
Regarding the first, you would have to pass the wl_client reference to the read function, which would mix API layers unnecessarily. wl_client_read is basically just a convenient wrapper around recvmsg, so it should expose the same result semantics of >0 (OK), == 0 (EOF), and <0 (error), as it already does. It is up to the caller to handle the cases, if only to provide different log messages for error and EOF.<br>
<br>
Regarding the second, wl_connection_read is part of the wayland private/internal API, and only used in two places: wayland-client.c, which already handles EOF in an appropriate manner, and wayland-server.c, where the proposed patch handles the missing case as well. If anybody else needs to use wl_connection_read within the wayland libraries in the future, they are hopefully aware of the recv result semantics. If necessary, maybe add some documentation to wayland-private.h.<br></blockquote><div><br></div><div>What I meant was to just make wl_connection_read return something consistent (< 0 on EOF). That said, if we're doing it this way in wayland-client, then I'm fine with it. I didn't actually go look.<br></div><div>--Jason Ekstrand<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> > }<br>
> > --<br>
> > 1.9.1<br>
> ><br>
> > _______________________________________________<br>
> > wayland-devel mailing list<br>
> > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br>
</div></div></blockquote></div><br></div></div>