<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 28 February 2013 20:02, Sam Spilsbury <span dir="ltr"><<a href="mailto:smspillaz@gmail.com" target="_blank">smspillaz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because all of the data has been read from the fd, there is a<br>
condition where we have read every single event that needed to be<br>
delivered to us. Then when we return to poll (), it will block<br>
indefinitely because there is nothing left in the fd for us to read,<br>
and the compositor isn't going to send us any more events. It might be<br>
possible to work around this by checking if events are available in<br>
the queue and calling poll () if there aren't any, but it seems like<br>
there is no API available to do so.<br></blockquote><div><br></div><div style>wl_display_dispatch_pending() will dispatch any events which have been read but not acted upon, in the default event queue. The documentation for that function has more information about that exact usecase.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wanted to know what the expected behaviour around this was meant to<br>
be. If eglSwapBuffers is meant to read () the fd, then that means that<br>
we need to rely on it being called in order to populate the event<br>
queue (since it can only be done in one place). That, in my opinion,<br>
feels like broken behaviour, because we might want to use the protocol<br>
to send data to clients which wouldn't necessarily result in a<br>
SwapBuffers, then those clients can't reliably call either<br>
wl_display_dispatch_pending () or wl_display_dispatch () with poll ()<br>
because there's no way of knowing whether or not that fd is going to<br>
block indefinitely or not.<br></blockquote><div><br></div><div style>Huh? wl_display_dispatch_pending() never blocks. Hence the suggestion to call it immediately before going into epoll/poll/select.</div><div style><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess I can make a few suggestions here...<br>
<br>
1. eglSwapBuffers could read a separate fd for new buffer info<br></blockquote><div><br></div><div style>Can't be done, as there are no cross-client resources.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. For roundtrip and SwapBuffers, we could make the server put some<br>
data back into the fd indicating that the fd has been read and events<br>
were put into the queue. That way, when main loops call poll () again,<br>
they will see data is available for reading -> wl_display_dispatch<br>
would read that "data", find no new events and dispatch the existing<br>
queue. Then if we don't SwapBuffers again and truly have no remaining<br>
events to be delivered, the next call to poll () would truly sleep<br>
until there was.<br></blockquote><div><br></div><div style>Ugh, that sounds nasty and trouble-prone.</div><div style><br></div><div style>Cheers,</div><div style>Daniel </div></div></div></div>