<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - wl_display_roundtrip() seems not thread-safe" href="https://bugs.freedesktop.org/show_bug.cgi?id=83304#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - wl_display_roundtrip() seems not thread-safe" href="https://bugs.freedesktop.org/show_bug.cgi?id=83304">bug 83304</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to <a href="show_bug.cgi?id=83304#c6">comment #6</a>) > (In reply to <a href="show_bug.cgi?id=83304#c4">comment #4</a>) > > > The deadlock is there, right below FIXME: > > > > > > <a href="https://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/wl/shm.c">https://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/wl/shm.c</a>; > > > hb=2.2.0-git-662-ge08f4fc#l184 > > > > That is broken like I explained above, it runs in a different thread, > > doesn't it? > > Yes. But now you seem to imply that running wl_display_roundtrip() in > parallel to a threaded mainloop is not meant to work. Well, the Wayland > developers are free to "define" their API the way they feel like, so that is > fine. > > But then I don't understand what you meant by "it all works if all threads > follow the polling protocol documented". That seems contradictory. The major point here is, that dispatching a queue from more than one thread is a bad idea. The event handlers called by dispatch are usually not written to be totally thread and async safe. Sometimes it is practically impossible to write them like that. wl_display_roundtrip() must dispatch the default queue, because it is waiting for an event on the default queue. That means you now have two different threads dispatching the same queue, and the event handler functions will be called in an arbitrary thread context. As you found out yourself, wl_display_roundtrip() itself (the handling of 'done' variable) is not written to work in that scenario. The algorithm there is fundamentally racy is multiple threads are involved in dispatch, and no barriers can fix it. Your semaphore replacement looks like it should work, but then it assumes that there actually is another thread dispatching the default queue. If you call your semaphore version from the "main" thread that is responsible for dispatching the default All threads following the polling protocol is one thing. Not dispatching a queue from multiple threads is another important thing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>