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

[Daniel Stone]

On 27 July 2013 19:28, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

Um, it's not a trick, it's exactly how GSource works ...

> 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
>>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel