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 bug 91273 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 bug 91767 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 bug 91766.

* wl_display_roundtrip_queue() exposes the race condition discussed above and in bug 91273. Any solution to bug 91273 needs to be suitable to wl_display_roundtrip_queue(). See bug 91768.