idle tasks starving in toytoolkit
tomeu at tomeuvizoso.net
Thu Oct 3 23:57:22 PDT 2013
On 27 September 2013 23:34, Daniel Stone <daniel at fooishbar.org> wrote:
> On 27 September 2013 05:38, Neil Roberts <neil at linux.intel.com> wrote:
> > Pekka Paalanen <ppaalanen at 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
It's maybe only demos what are drawing directly from the frame
callback, but there's lots of them and it will confuse people.
More information about the wayland-devel