Wayland client library thread safety

[Arnaud Vrac]

On Fri, Apr 20, 2012 at 6:33 PM,  <darxus at chaosreigns.com> wrote:
> I guess you're not going to get a useful response here.
> That seems really unfortunate to me.  Please open a bug
> here, so we at least have a proper record of the problem:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland

Thanks darxus, I don't mind posting a bug bug is anyone actually going
to use this bugtracker ? It's empty :)

>
> On 04/19, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backend. The problem is that Qt5
>> (QtQuick2 actually) renders in a separate thread, when the wayland
>> display has been created in the main thread. I know there is a patch
>> for "thread affinity" in qtwayland to solve this, but it is wrong and
>> breaks other clients.
>>
>> Since it is required from the EGL spec to be able to render in
>> multiple threads, how can this be solved ? Does the wayland backend
>> for mesa support this properly ? I don't see how it can work since
>> even writes in the connection queue are not protected.
>>
>> Here is a crude extract from my EGL backends where wayland can fail
>> because of thread concurrency:
>>
>> - SwapBuffers:
>>
>> while (!swap_done) {
>>   wl_display_flush()
>>   // wait frame callback
>>   wl_display_iterate(WL_DISPLAY_READABLE)
>> }
>>
>> wl_surface_frame()
>> wl_surface_attach()
>> wl_surface_damage()
>> lock_back_buffer()
>> swap_buffers()
>>
>> - GetBuffers (called on makeCurrent or at the first gl call after swap)
>>
>> while (no_buffer_unlocked)
>>   wl_display_flush()
>>   // wait for a buffer to be released
>>   wl_display_iterate(WL_DISPLAY_READABLE)
>> }
>>
>> Thanks for your help,

-- 
rawoul