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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
