On 27 September 2013 23:34, Daniel Stone <dan...@fooishbar.org> wrote: > > Hi, > > On 27 September 2013 05:38, Neil Roberts <n...@linux.intel.com> wrote: > > Pekka Paalanen <ppaala...@gmail.com> writes: > >> If not, is there not a possibility to break existing applications by > >> blocking too early? > > > > Yes, you're right, the patch is nonsense because it won't work when the > > application does wl_display_dispatch_pending because it might end up > > with some events still in the queue but the poll won't wake up to > > process them. > > Indeed, it doesn't solve the original problem at all, because you just > have to keep dispatching randomly and hope for the best. > > > It would be nice if the recommended main loop was more like this: > > > > [snip horrible unpleasantness] > > > > That way it doesn't matter if wl_display_dispatch_pending doesn't clear > > all of the events. > > Ugh. I really don't like the look of that; would be nice to have a > wl_display_dispatch_some_subset_of_pending(), which would return > failure / dispatched everything / still stuff left to dispatch. But I > worry this takes us into libdbus API design territory ...
Or we can just document that causing a connection read from within an event handler can cause wl_display_dispatch to never exit, or even raise an error and exit if we detect a nested call to wl_display_dispatch_queue. It's maybe only demos what are drawing directly from the frame callback, but there's lots of them and it will confuse people. Regards, Tomeu _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
