Wayland client library thread safety

Bill Spitzak spitzak at gmail.com
Fri Apr 20 14:56:39 PDT 2012

Kristian Høgsberg wrote:

>> 1) Toughen up and add locking around all access to wl_display.  It's
>>   not as much code as it sounds, there are actually only a few entry
>>   points that need locking.

This could be free if the *caller* is required to lock/unlock. Ie there 
is a wl_lock/unlock call that you must use around all other use of 

Programs won't have to call this if they are single threaded, or 
(because they already have locking around the relevant code) they know 
that they are already preventing multiple threads from interacting. The 
calls can also surround multiple wayland calls, which is more efficient, 
and can also allow relying on the state being unchanged between them.

Possibly you are already considering this. I apologize if I am just 
restating the obvious implementation.

>>   The
>>   idea here is to introduce a wl_display_iterate_for_object() entry
>>   point that will only call out for events addressed to that object
>>   and queue up the rest.

It sounds like adding this call would avoid the need for thread affinity 
and any other blocking of events that you describe. Instead the calling 
program can use this entry point to limit callbacks to objects it knows 
will work.

More information about the wayland-devel mailing list