Should there be a way to query if an event queue is empty?

[Bill Spitzak]

I think that rather than some trick to fool glib into making the poll 
return immmediately, calling dispatch_pending in a loop until it returns 
false will work better, and the poll can be called normally.

If glib does not reliably call something before the poll (possibly 
documented as something "after the last dispatch function", as the end 
of the loop is identical to the start of the next loop) then I don't see 
any way to fix this other than to change glib, or require that all 
dispatch functions know about wayland and call the wayland dispatch.

On 07/27/2013 06:16 AM, Neil Roberts wrote:
> Bill Spitzak <spitzak at gmail.com> writes:
>
>> You can call dispatch_pending "last", ie as part of the dispatch
>> function. It's in a loop, so doing something at the end of the loop is
>> the same as doing it at the start.
>
> I don't think that will work for GLib because you can't really control
> the order of the dispatch functions to make sure that the dispatch for
> the Wayland source will be invoked last. That means that for example if
> you have a different source that causes a redraw which calls
> eglSwapBuffers, that will cause Mesa to dispatch events for its own
> event queue. That could also cause events to be queued for the main
> event queue. If the redraw source is dispatched after the Wayland source
> then nothing will cause poll to wake up even though there are events
> that are immediately ready to be dispatched.
>
> Having thought about this a bit more I think in the GLib case you could
> just use wl_dispatch_prepare_read() because that does effectively let
> you know whether there is anything in the queue. So you could call it
> once in the prepare function and if it errors with EBUSY then you could
> return TRUE to cause poll to wake up immediately and then in the
> dispatch you would call wl_display_dispatch_pending instead of
> wl_display_dispatch. This would probably be a good thing to do anyway to
> make it thread safe.
>
> This relies on being able to guarantee that the prepare function will be
> called exactly once before entering poll and that the check function is
> guaranteed to be called after exiting poll. Otherwise you can't match
> the prepare_read with a read or a cancel. I think for a GSource this is
> probably true so it won't cause any problems. However for Cogl we can't
> currently guarantee that the prepare function will exactly tally up with
> the dispatch function because these are driven by calls from the
> application. However I'm not sure whether that is more a problem with
> Cogl's design rather than Wayland's design.
>
> Regards,
> - Neil
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>