<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - It's not safe to share wl_display fd with other threads."
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91273#c2">Comment # 2</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - It's not safe to share wl_display fd with other threads."
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91273">bug 91273</a>
              from <span class="vcard"><a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> <span class="fn">Jonas Ådahl</span></a>
</span></b>
        <pre>(In reply to Boram from <a href="show_bug.cgi?id=91273#c0">comment #0</a>)
<span class="quote">> Created <span class="bz_obsolete"><a href="attachment.cgi?id=117010" name="attach_117010" title="simple test application to reproduce this bug">attachment 117010</a> <a href="attachment.cgi?id=117010&action=edit" title="simple test application to reproduce this bug">[details]</a></span>
> simple test application to reproduce this bug</span >

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

<span class="quote">> 
> 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.</span >

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.

<span class="quote">> 
> Real example:
> gstreamer's waylandsink can do polling on same diplay fd of toolkit's
> main-thread(Such like GTK and EFL...).
> (<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/wayland/">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/wayland/</a>
> 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.</span >

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

<span class="quote">> 
> 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?</span >

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:
<a href="http://lists.freedesktop.org/archives/wayland-devel/2015-June/023054.html">http://lists.freedesktop.org/archives/wayland-devel/2015-June/023054.html</a>

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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>