Wayland client library thread safety

Arnaud Vrac rawoul at gmail.com
Tue Apr 24 09:15:12 PDT 2012

2012/4/24 Bill Spitzak <spitzak at gmail.com>:
> 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"?

Because eglSwapBuffers is unfortunately a blocking call.

>> 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.


More information about the wayland-devel mailing list