Wayland client library thread safety
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.
>> 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
More information about the wayland-devel