<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - It's not safe to share wl_display fd with other threads." href="https://bugs.freedesktop.org/show_bug.cgi?id=91273#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - It's not safe to share wl_display fd with other threads." href="https://bugs.freedesktop.org/show_bug.cgi?id=91273">bug 91273</a> from <a class="email" href="mailto:boram1288@gmail.com" title="Boram <boram1288@gmail.com>"> Boram</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=91273#c4">comment #4</a>) > (In reply to Boram from <a href="show_bug.cgi?id=91273#c1">comment #1</a>) > > Created <a href="attachment.cgi?id=117011" name="attach_117011" title="simple test application to reproduce this bug">attachment 117011</a> <a href="attachment.cgi?id=117011&action=edit" title="simple test application to reproduce this bug">[details]</a> > > simple test application to reproduce this bug > > It seems you are misusing the API; you are mixing wl_display_dispatch() with > wl_display_prepare_read() and friends. See the paragraph of multi threaded > environments in the API documentation: > <a href="http://wayland.freedesktop.org/docs/html/apb.html#Client">http://wayland.freedesktop.org/docs/html/apb.html#Client</a>- > classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d Actually, I only simplified what gtk & waylandsink do, and combined them into one test application to reproduce and explain bug easily. GTK, EFL and weston-client applications use same APIs. They call wl_display_flush & wl_display_dispatch_pending for prepare step and call wl_display_dispatch for read & dispatch step. I already read the API documentation as well as wayland-client source code also. And I fully understand what you say. I had questions why these toolkits and weston-client applications use wl_display_dispatch instead of prepare_event, read_event? why gstreamer's waylandsink uses prepare, read_event? After reading documentation, now I understand. The main-thread of client applications & toolkits with mesa gl acceleration can be blocked if they use prepare_read & read_event because mesa call wl_display_dispatch_queue internally. And gstreamer's waylandsink faithfully follows the API documentation. So, I couldn't blame one of them. I guess toolkits, weston-client and gstreamer have their own good reasons why they use that kind of APIs. Anyway, my point of this report is "In case of sharing and polling fd, it's possible for kernel not to wake up the thread. Then, the thread can be blocked". Even if we use properly APIs as the API docuementation, I think this bug can't be solved.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>