Expected behaviour of eglSwapBuffers and the event queue

[Uli Schlachter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 01.03.2013 06:08, Sam Spilsbury wrote:
[...]
>>> 3. For roundtrip and SwapBuffers, we could make the server put some 
>>> data back into the fd indicating that the fd has been read and events 
>>> were put into the queue. That way, when main loops call poll () again, 
>>> they will see data is available for reading -> wl_display_dispatch 
>>> would read that "data", find no new events and dispatch the existing 
>>> queue. Then if we don't SwapBuffers again and truly have no remaining 
>>> events to be delivered, the next call to poll () would truly sleep 
>>> until there was.
>> 
>> 
>> Ugh, that sounds nasty and trouble-prone.
> 
> Yeah, could be ugly. I'm wondering if that's how Xlib/xcb does it though -
> eg, you might make a request that requires a roundtrip, which would
> necessitate reading events out of the fd until you got your reply. If there
> were no more events delivered after that then surely we have to do
> something to ensure that clients don't block forever in poll ().

With Xlib, that thing is XPending(). With xcb, I guess it would
xcb_poll_for_queued_event().

I learned that qt5 starts a new thread that sits in xcb_wait_for_event() all
the time. This makes sure that there is always a thread that gets woken up on
pending events and can then wake up the main thread. Thanks to xcb's
thread-safeness, this makes sure no event is forgotten. So far I haven't heard
about any approach which avoids this thread.

With Xlib, qt didn't need to do this. The reason that I think I heard is that
Xlib is thread-unsafe enough that only the main thread is allowed to touch the
Display* and thus it is enough if the main thread checks with XPending()
before going to sleep.

Of course such an approach isn't possible since there is a race where after
calling XPending() and before going into poll()/select(), another thread could
read events from the fd which now sit indefinitely wait in some event queue.

(Internally, xcb uses a linked list of reply waiters and some condition
variables to make sure that threads get woken up. Of course, something like
that is a terrible public API and is not exported)

Cheers,
Uli
- -- 
"For saving the Earth.. and eating cheesecake!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJRMG5QAAoJECLkKOvLj8sGHFEH/1jWR/6P0mzk2YxsWk7daJB+
u4nj+brlaONLh7Uy6C3Dg0OF20BgS/SHFwrUBsuqLUNQkEtm/bonPsnctqFrYW6c
9H+YcKxzj+3OQn17dRzYlTHoF3FEmV2Oa/V+uMdkMkQOBddM5Uwdgwb/yqPshSZd
RWeqpUVbWxS/HlHsPABDpYsOTF5632L1A1MwBoHDT8lDllgCI9C8QcBGxgo4RJ9Y
AGrZRTKCKDOVIMfuKriL1Eax1fLQ1T1VPqK4VU+HQQt8CYfvF7wIHFRBOzGTXup0
N4Vvdv4te6uYBbdHQ7hWB08qJMf0c5VzuLOe5KnHaqFmUqk1x+gAGd5ePaJzQ+Y=
=apQq
-----END PGP SIGNATURE-----