Wayland client library thread safety

[Kristian Høgsberg]

On Fri, Apr 20, 2012 at 5:56 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

You're restating the email you're replying to:

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

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

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.

Kristian