[Wayland-bugs] [Bug 91273] Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Sep 7 01:12:34 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=91273

--- Comment #12 from Jonas Ã…dahl <jadahl at gmail.com> ---
(In reply to Boram from comment #11)
> > All threads call wl_display_read_events() after returning from poll(), but
> > only the last thread reads the data from the fd.  That way we make sure all
> > threads who called wl_display_prepare_read_queue() will come out of poll
> > before we read the data.
> 
> In multi-thread application, looks we need to avoid to use
> dispatch()/dipatch_queue(). And there might be no problem if every threads
> call prepare_read(), poll() and read_events(). For toolkits to support
> multi-thread, they also need to be fixed to use prepare_read/read_events, as
> well as mesa Pekka Paalanen mentioned above.
> 
> To replace roundtrip()/dispatch()/dispatch_queue(), can wayland offer a new
> convenient API which internally calls poll() and read_events()? i.e,
> wl_display_poll_read()? It will be more convenient than calling poll() and
> read_events() directly by each library.

It is more or less fine to use dispatch()/dispatch_queue() in a multi-threaded
application as long as one deals with tear-down appropriately and dispatches
the right queue on the right thread. See bug 91767 and bug 91769 for more
details.

We aim to fix these issues shortly after the coming release.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150907/364c87fb/attachment.html>


More information about the wayland-bugs mailing list