<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#c8">Comment # 8</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#c7">comment #7</a>)
<span class="quote">> > I still don't understand what you mean by "the kernel may not wake up the
> > thread" if it refers to a different issue than the two mentioned above.
>
> When A thread is polling on a display fd and B thread is polling on the same
> display fd, if a server sends messages, sometimes only one thread(Let's say
> it is B thread) awakes and reads all events so fast. Then A thread still is
> in the polling status and can't awake. Even if B thread reads and queue all
> events into corresponding queue_lists, the events of A thread's queue_list
> can't be handled because A thread is still in sleep.</span >
When the API is used correctly, all threads will have exited the poll() call
and either canceled the read, or entered the read phase, so the scenario you
describe won't happen. Note that no thread will ever read from the fd until
*all* threads that called prepare_read has either called cancel_read or
read_events.</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>