Thread safety when rendering on a separate thread

[Pekka Paalanen]

On Mon, 27 Jan 2020 12:36:27 +0100
Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:

> Hi,
> 
> El lun., 27 ene. 2020 a las 12:07, Pekka Paalanen
> (<ppaalanen at gmail.com>) escribió:
> >
> > On Mon, 27 Jan 2020 11:43:50 +0100
> > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> >  
> > > Hi all,
> > >
> > > I have a Wayland client where the main loop runs on a thread and
> > > rendering is done in a separate thread. The main loop simply uses
> > > wl_display_dispatch:
> > >
> > > while (wl_display_dispatch(globals.display) != -1) {
> > >     [...process user input...]
> > > }
> > >
> > > This is the only place where events are processed.
> > >
> > > Rendering however is done on a separate thread, which eventually ends
> > > up calling:
> > >
> > > wl_surface_attach(surface, buffer, 0, 0);
> > > wl_surface_damage(surface, x, y, width, height);
> > > wl_surface_commit(surface);
> > > wl_display_flush(display);
> > >
> > > Is this safe or do I need to do any additional locking / synchronization?  
> >
> > Hi,
> >
> > that depends.
> >
> > First thing is if you have event handlers, for example wl_callback.done
> > for wl_surface.frame which you really should be using to throttle your
> > rendering. Event callbacks get dispatched from where the dispatch
> > function is called, so that could race with your rendering thread.
> >
> > Another thing is window management. If you handle xdg_toplevel events
> > and set window state while your animation is already running, it
> > depends on from which thread you send the window state requests. If you
> > send those from the rendering thread, it's fine. If you send those from
> > the main thread, then they will race against your rendering thread
> > sending wl_surface.commit. In some cases that might even lead to fatal
> > protocol errors as you cannot reliably operate the protocol correctly.
> >
> > Usually when threads are involved, you dispatch the wl_display itself
> > in one thread, and for each other thread touching Wayland you create a
> > new wl_event_queue and with the help of wl_proxy_create_wrapper() you
> > assing new protocol objects to the appropriate queue. This ensures the
> > dispatching will happen in the thread where you want it.  
> 
> Thank you for your answer. This is an embedded fullscreen application, so no
> window management.

Fullscreen is one of the modes where you need to be careful with your
window size and synchronise correctly to obey the compositor's demands.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200127/486c54eb/attachment-0001.sig>