Wayland client library thread safety

[Bill Spitzak]

Pekka Paalanen wrote:

> There was some talk about an alternative implementation: to let
> eglSwapBuffers never block, instead block when a rendering operation is
> about to use a buffer that should have already been made available by
> swapBuffers, but didn't actually happen yet. The DRM architecture
> should allow this. I wonder if this idea was forgotten or deemed to
> have problems...

I think the problem is that this would have to be tested for in 
virtually every EGL call, which may not be great for speed.

What I was proposing is that a wayland-aware egl code could use 
alternative calls so the swap is started without blocking, and another 
call to find out when the swap finishes. It's no longer using the egl 
interface, instead it is cheating and calling directly the stuff that 
eglSwapBuffers calls.

In any case none of this makes any difference to the underlying problem 
because there is still a blocking call in both of them.

> Related to the above idea, the "buffer is now ready to be drawn to
> again" event could be delivered out-of-band, i.e. not in Wayland
> protocol stream, but e.g. via DRM. This is alternative to the DRM
> automatically blocking the client process on a rendering command.

This sounds like the right answer to me. Waiting for the buffer to be 
ready wants to ignore every event other than the buffer-release.

> But all this still leaves the problem: eglSwapBuffers must send a
> Wayland attach request, and it may happen in a different thread than
> where the wl_display is being used. I believe this is the primary
> reason for "EGL makes [the old design] impossible".

This would work with client-controlled locking. The eglSwapBuffers 
implementation would call wl_lock()/wl_unlock() around the attach call, 
even though manually calling them is necessary in code directly calling 
wayland. This is because the egl emulation is more like a client library.