Wayland client library thread safety

[Bill Spitzak]

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

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.