Thread affinity again

[Bill Spitzak]

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

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