Thread affinity again
spitzak at gmail.com
Thu May 10 12:03:02 PDT 2012
Jørgen Lind wrote:
> Hi guys.
> I have implemented a proposal for thread affinity for libwayland-client.
> By this I mean that proxies belong to threads. So events will be
> dispatched in the thread that created the proxy. Obviously proxies can
> be moved between threads if that is desired.
> As a side-effect I also implemented a wl_display_iterate_for_object
> which takes a proxy and only dispatches events for that proxy,
> effectively queuing up all other events.
My impression is that what is needed is a call that *only* gets
buffer-release events for a particular object. Other events for that
object are *not* wanted. Since they are rare it is quite likely an app
will have not debugged handling these events, and doing things like
recursively calling this same wait function because the event triggered
another buffer swap may be disasterous.
I am also very wary of this idea of thread affinity. I am MUCH more
interested in having a "main" thread that gets all the wayland events,
no matter what thread created the objects. The main thread is identified
by being the one that calls "wait_for_next_event_from_wayland()".
Windows is a total PITA because of it's thread affinity and it would be
nice if wayland did not do this. Despite all it's problems, X11's
behavior is a huge win here and makes it enormously easier to program a
Of course you suggest that the thread affinity can be changed, so this
fixes the problem considerably. There could also be a "I want all
events" setting when calling for events that ignores thread affinity.
The suggestions that the buffer release be a different socket sound like
the real solution to the underlying problem. Even with thread affinity
for events this is still going to be needed, due to clients wanting to
wait for the buffer release and not have any calls happen during that
time, since they are in a temporary state where the buffer pointers are
More information about the wayland-devel