Wayland client library thread safety

[Bill Spitzak]

On 04/24/2012 09:13 AM, Arnaud Vrac wrote:

> Still keep a single wl_display with proper locking, and add a
> wl_connection for each thread. For the wl_display thread, the
> connection would still be made through the unix socket, while for the
> other thread you would prepare a socketpair on the client side and
> send the peer fd through the main connection. This way you only need
> one fd for each thread which can be polled for read and write, like
> for the main thread. This also means that objects are implicitly
> shared between threads, like in solution 1.

However it sounds like the events for an object are delivered to a 
particular thread, and it is difficult or impossible to change this thread.

This was a huge problem with WIN32 and it would be nice to avoid it. A 
common use in toolkits is that *all* the events (except for internal 
details such as waiting for buffers to be unused) want to go to the main 
thread, so that handlers for keyboard and mouse clicks can be done 
sequentially without locking. In WIN32 I was forced to make a 
between-thread message passing system that deferred all creation of 
system objects so that they were made by the main thread (and of course 
this sent all events to the main thread, even the ones like the buffer 
wait that really wants to belong to the rendering thread).

I think the client should be able to decide, at the moment a thread 
waits for events, what objects it should get the events for. So, if I 
understand it right, solution 1 is much closer to what is needed.