<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#c2">Comment # 2</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>Yeah, I don't think wl_display_roundtrip() is thread-safe. It's really the same thing that dispatching the same queue from multiple threads is a bad idea. You should really have a queue dedicated to each thread, and dispatch that queue only from that exact thread, never from any other thread. Otherwise your event handlers become quite a bit complex and hard to make reliable. It might even be impossible to implement correct locking for your own data structures without a dedicated queue. You always want to know in which thread your callbacks will run, and creating a new queue and using it consistently is the tool to achieve that. Unless you are running in the thread that dispatches the default queue (the queue built in to wl_display), do not use wl_display_roundtrip(). Instead, use wl_display_roundtrip_queue() which is new in 1.6, or open-code that if you need to work with older libwayland-client. Also, I think the docs on wl_display_dispatch_queue are outdated a bit: * This function blocks if there are no events to dispatch. If calling from * the main thread, it will block reading data from the display fd. For other * threads this will block until the main thread queues events on the queue * passed as argument. Nowdays, any thread can read the fd, but it all works, if all threads follow the polling protocol documented for wl_display_prepare_read(). I'm leaving this bug open, so that we would remember to check the documentation.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>