Wayland client library thread safety

[Bill Spitzak]

On 04/20/2012 03:27 PM, Kristian Høgsberg wrote:

> "Initial assumption for wl_display and related objects was that it is
> not going to be thread safe, and you have to lock access to the wl API
> yourself if you're going to use it from multiple threads.  It's a
> valid assumption and it avoids fine grained API level locking, and in
> many cases, wl would be integrated into an existing mainloop that
> solves locking.  Of course, EGL makes that kind of design impossible."

Sorry for probably wasting your time, but why does "EGL make this 
impossible"?

> No it's not enough, the main thread is going to do
> wl_display_iterate() for everything else and it needs to know to not
> handle objects that belong to other threads.

If thread affinity is added, please make sure the client can change 
which thread an object goes to. Windows (at least the classic interface) 
did not do this and it was very frustrating, what I needed was to create 
objects in any thread, but have all events handled by the main thread. 
In the end we had to limit what users of the library could do in 
parallel threads because of the inability to do this.

Easiest way I can see is to allow a thread id to be attached to an 
object by the client, and for the client to send the same thread id when 
calling. Then the method of identifying a thread is left up to the 
client instead of wayland. It would all be done by the client-side of 
the library, the compositor does not know about this.

Arbitrary "sets" of objects might be useful. A single object, all 
objects, and all objects belonging to a thread are examples of sets. 
Then the wl_display_iterate could take a set-id to limit the callbacks 
to the sets. For efficient implementations perhaps there is a limit of 
32 sets (other than the single object and 'all' sets) and membership is 
a bitflag on the object.