Wayland client library thread safety

[Bill Spitzak]

On 04/24/2012 09:15 AM, Arnaud Vrac wrote:

>> Sorry for probably wasting your time, but why does "EGL make this
>> impossible"?
>
> Because eglSwapBuffers is unfortunately a blocking call.

After reading all these emails a bunch more times, I *think* I 
understand the problem.

First of all, this is for "EGL atop Wayland" (an EGL implementation that 
uses Wayland), not "Wayland atop EGL" (a Wayland compositor that uses 
EGL to do all it's work). That is mostly what confused me.

The EGL spec says that after eglSwapBuffers returns the former back 
buffer is not being used for display and can be drawn on. Unless an 
otherwise unnecessary copy is done, the only way to do this in Wayland 
is to do an attach and then wait for Wayland to respond that the old 
buffer is not attached any more. This is the blocking, correct?

This is less than ideal. If a thread wants to update two EGL surfaces, 
it cannot start the swap on the second one until the first one finishes 
swapping, and can't draw anything in the second one while waiting for 
the swap of the first. Therefore I would expect a non-EGL workaround to 
be added that allows this, perhaps a client can call wl_egl_start_swap() 
and later wl_egl_wait_for_swap(). eglSwapBuffers would just do these two 
in a row.

I think the thread is only interested in buffer-free events and are 
unprepared for mouse clicks to be handled while they are still cleaning 
up their drawing (I would not be surprised if the mouse click tries to 
grab the same lock the drawing code is holding and deadlocks). So it is 
much more likely that any filtering of events is "only do callbacks for 
buffer-free events for this object", not "only do callbacks for this 
object".

So I would propose that the actual problem be attacked. I think what is 
needed "wl_wait_for_buffer_release(surface)" api. The result of this 
call is that when it returns you know that all attach calls for this 
surface have completed (it would return immediately if there were no 
attach calls). No callbacks would happen in this thread while it is 
waiting. There should also be client-level locking of wayland, a 
multithreaded client must itself lock wayland around any calls, 
including this one (calls that block will internally release the lock 
while blocking).

I'm not sure if this solves anything, but I think limiting the problem 
to this one call makes it easier to think about solutions, and also 
provides a call that is useful for other drawing systems than EGL. One 
idea this makes possible is to put the buffer-release events into their 
own socket.