On 27 July 2013 19:28, Bill Spitzak <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
