<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - wl_display_dispatch(_queue) documentation about thread safeness is probably wrong" href="https://bugs.freedesktop.org/show_bug.cgi?id=91767#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - wl_display_dispatch(_queue) documentation about thread safeness is probably wrong" href="https://bugs.freedesktop.org/show_bug.cgi?id=91767">bug 91767</a> from <a class="email" href="mailto:mchqwerty@gmail.com" title="Marek Chalupa <mchqwerty@gmail.com>"> Marek Chalupa</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=91767#c0">comment #0</a>) > There is documentation about wl_display_dispatch() states one may not mix > wl_display_dispatch(_queue) with wl_display_prepare_read() and friends, but > this is probably a common misconception, because internally, > wl_display_dispatch_queue() is implemented in the same way as one would use > wl_display_prepare_read() and friends, just without using those functions. > > I have patches in progress that changes wl_display_dispatch_queue() to > simply use wl_display_prepare_read() and related API internally to make this > more obvious. I forgot not only the details :) But looking into the code... Clearly you cannot do something like: wl_display_prepare_read() wl_display_dispatch() in one thread, that would leak to dead-lock. You're right that the wl_display_dispatch() works on the same basis as the prepare+read API. I think that they should not be mixed for the same reason you cannot call wl_display_dispatch_queue() from more threads. That is, there is (probably) no dead-lock, but thread can get sleeping with events queued. <a href="http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1454">http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1454</a> If you call prepare + poll + read in thread A and wl_display_dispatch_queue() in another thread B (dispatching two different queues), the fd could become readable before wl_display_dispatch_queue() calls poll (<a href="http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1574">http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1574</a>) and whole prepare+read sequence could run before it, queing events into both queues. After prepare+read queued events, thread B goes to sleep in poll with events hanging in the queue. Avoiding this behaviour was why wl_display_prepare_read() and wl_display_read_events() API was added and why programs dispatching events from more threads should use it, while programs with single dispatcher thread can use the usual wl_display_dispatch_...() Implementing wl_display_dispatch(_queue) using prepare+read should fix this IMHO.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>