idle tasks starving in toytoolkit

[Tomeu Vizoso]

On 27 September 2013 23:34, Daniel Stone <daniel at fooishbar.org> wrote:
>
> Hi,
>
> 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
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