<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Meta bug for libwayland-client threading issues"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91769">91769</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Meta bug for libwayland-client threading issues
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>wayland
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jadahl@gmail.com
</td>
</tr></table>
<p>
<div>
<pre>Currently, as of 1.8 (and the coming 1.9), there are several issues with the
meant to be thread safe API. This bug report is the meta bug of the different
ones that are known.
The known issues at the point of the reporting of this bug are:
* The setup of wl_proxy (or, rather, setting the wl_proxy queue) is racy in
multi threaded architectures.
If thread A creates a proxy meant to be dispatched on a queue only used on that
thread, while another thread B is reading and dispatching the default queue, it
may happen that the thread B reads and dispatches events sent to the proxy just
created by thread A, before thread A had the chance to set the queue of the
proxy to its own. The reason for this is that the sequence "proxy =
wl_proxy_create(...); wl_proxy_set_queue(proxy, queue);" is not atomic, and the
state between the calls is that the proxy has the default queue. Would thread A
yield there, and input already be available, thread B would read and dispatch
the event on the default queue, i.e. on the wrong thread. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - It's not safe to share wl_display fd with other threads."
href="show_bug.cgi?id=91273">bug 91273</a> for
more info.
* The documentation for wl_display_dispatch() and wl_display_dispatch_queue()
states that they may not be mixed with wl_display_prepare_read() and friends.
This is likely incorrect, since wl_display_dispatch(_queue) more or less does
what a client would do when using wl_display_prepare_read() etc. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - wl_display_dispatch(_queue) documentation about thread safeness is probably wrong"
href="show_bug.cgi?id=91767">bug 91767</a>
for more info.
* Using either the wl_display_dispatch(_queue) or by following the code samples
about how to use wl_display_prepare_read() and friends, one cannot cancel a
dispatch call without some input being available on the fd. In effect, this
means that there is no reliable way for a client to disconnect when using the
dispatch helpers. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - There is no way to cancel wl_display_dispatch(_pending) call without a server roundtrip"
href="show_bug.cgi?id=91766">bug 91766</a>.
* wl_display_roundtrip_queue() exposes the race condition discussed above and
in <a class="bz_bug_link
bz_status_NEW "
title="NEW - It's not safe to share wl_display fd with other threads."
href="show_bug.cgi?id=91273">bug 91273</a>. Any solution to <a class="bz_bug_link
bz_status_NEW "
title="NEW - It's not safe to share wl_display fd with other threads."
href="show_bug.cgi?id=91273">bug 91273</a> needs to be suitable to
wl_display_roundtrip_queue(). See <a class="bz_bug_link
bz_status_NEW "
title="NEW - wl_display_roundtrip_queue() exposes the wl_proxy_set_queue() race"
href="show_bug.cgi?id=91768">bug 91768</a>.</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>