[Wayland-bugs] [Bug 91273] It's not safe to share wl_display fd with other threads.

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Boram from comment #0)
> Created attachment 117010 [details]
> simple test application to reproduce this bug

Please attach the source code for the test application instead of the binary (I
only see garbage when opening the attachment in the browser).

> 
> Condition:
> 2 threads polling on same display fd in both threads.
> 
> Result:
> When one thread awakes, if it quickly reads all events from display fd
> before kernel wakes up another, then another can't awake from poll(). I
> attached a very simple test application to reproduce this.

The API is made so that when there are multiple threads reading from the fd,
they don't do so until every thread has returned from poll(). When every thread
that want data from the fd calls "prepare read", only one will actually read it
in the end, after all threads that are poll():ing should have seen that data is
on the fd.

> 
> Real example:
> gstreamer's waylandsink can do polling on same diplay fd of toolkit's
> main-thread(Such like GTK and EFL...).
> (http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/wayland/
> wldisplay.c)
> If waylandsink's thread reads all event using wl_display_read_events before
> toolkit's main-thread awakes, although all events are queued into
> corresponding event queues, default queue's events can't be handled because
> main-thread is still sleeping.

All threads that called prepare_read need to either cancel or read, and not
until then will one thread actually read the data.

> 
> Comment:
> poll(), select()... seems not guarantee that kernel will wake all threads up
> when events happen. Creating new queue seems a good solution if we want to
> handle  events of a certain wl_proxy. But not in this case. Maybe using a
> different display fd will be a good solution. But for using a different
> display fd, we have to create new display, then waylandsink can't use parent
> surface and create subsurface. Or else, can it be solution creating new fd
> for each queue?

I suspect the issue you are seeing is the race between creating the wl_callback
and setting the queue and listener, meaning the callback might be dispatched on
the main thread before the proxy got its listener configured.

The issue was discussed on IRC and also on the mailing list starting here:
http://lists.freedesktop.org/archives/wayland-devel/2015-June/023054.html

There is currently a potentially working work-around (with some side effects)
which is to wrap the sync callback proxy creation and setup inside a
prepare_read and a cancel_read in order to block any other thread from reading
and dispatching during the setup of the proxy.

-- 
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/20150709/30967c15/attachment.html>