[Wayland-bugs] [Bug 91750] Wayland may have interface bug when multi-threads programing.

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 25 01:16:56 PDT 2015


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

Jonas Ådahl <jadahl at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppaalanen at gmail.com

--- Comment #4 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Yujie Shen from comment #3)
> (In reply to Jonas Ådahl from comment #2)
> > Hi and thanks for the report. This seems to be a duplicate of bug 91273, so
> > closing this one. The problem can be worked around by using the current API
> > to block dispatching on other threads (see the last paragraph of (omment 2
> > of bug 91273 <https://bugs.freedesktop.org/show_bug.cgi?id=91273#c2>. You
> > will need this until we decide what API we want to introduce fix the issue
> > properly.
> > 
> > *** This bug has been marked as a duplicate of bug 91273 ***
> 
> Thank you.
> But,this bug is totally different from bug 91273.
> Bug 91273 reports a bug that 2 threads polling on same display fd in both
> threads.
> My bug,namely Bug 91750,reports a bug that a wl_proxy's property is still
> being modifying in a thread,while another thread may have sent it to server.
> Please kindly check the attachment"wayland multi-threads interface bug"again.

I still think this is the same issue, just that wl_display_roundtrip_queue()
exposes it. What should happen is that wl_display_roundtrip_queue constructs
and sets correct queue atomically, and because it fails to do this, the race
you describe happens (the proxy ending up on the default queue, being accessed
from the wrong thread).

The current work-around you can do is, with the code below as base.

...
    wl_surface_attach();
    wl_display_prepare_read(display);
    window->callback = wl_surface_frame(window->surface);
    /* surface_frame.callback event will not be queued nor dispatched,
         * at this point, because the "prepare_read" call above blocks other
     * threads from it.because
     */
    wl_proxy_set_queue(window->callback,queue2);
    wl_callback_add_listener(window->callback, &frame_listener, window);
    wl_display_cancel_read(display); /* This will effectively unblock other
dispatching threads. */
    wl_surface_commit(window->surface);


The difference to your example below is the wl_display_prepare_read(display)
before creating the proxy, and wl_display_cancel_read(display) after setting
the queue. The effect is that the other thread will not dispatch it, since it
will only the dispatch events on the queue associated with it.

Now, wl_display_roundtrip_queue() is a function that currently exposes the bug,
but I'm not sure what unforseen side effects would be to add a work-around like
the above, and whether it is a good idea to do it. The obvious side effect
would be stalling other dispatcher threads a bit more than before.

Pekka, any opinions whether we should temporarly "fix"
wl_display_roundtrip_queue() until we introduce some new API?

-- 
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/20150825/999e2028/attachment.html>


More information about the wayland-bugs mailing list