idle tasks starving in toytoolkit

Tomeu Vizoso tomeu at
Thu Oct 3 23:57:22 PDT 2013

On 27 September 2013 23:34, Daniel Stone <daniel at> wrote:
> Hi,
> On 27 September 2013 05:38, Neil Roberts <neil at> wrote:
> > Pekka Paalanen <ppaalanen at> 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 mailing list