On 04/20/2012 03:27 PM, Kristian Høgsberg wrote:
"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."
Sorry for probably wasting your time, but why does "EGL make this impossible"?
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.
If thread affinity is added, please make sure the client can change which thread an object goes to. Windows (at least the classic interface) did not do this and it was very frustrating, what I needed was to create objects in any thread, but have all events handled by the main thread. In the end we had to limit what users of the library could do in parallel threads because of the inability to do this.
Easiest way I can see is to allow a thread id to be attached to an object by the client, and for the client to send the same thread id when calling. Then the method of identifying a thread is left up to the client instead of wayland. It would all be done by the client-side of the library, the compositor does not know about this.
Arbitrary "sets" of objects might be useful. A single object, all objects, and all objects belonging to a thread are examples of sets. Then the wl_display_iterate could take a set-id to limit the callbacks to the sets. For efficient implementations perhaps there is a limit of 32 sets (other than the single object and 'all' sets) and membership is a bitflag on the object.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
