<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#c9">Comment # 9</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:krh@bitplanet.net" title="Kristian Høgsberg <krh@bitplanet.net>"> Kristian Høgsberg</a> <pre>(In reply to Boram from <a href="show_bug.cgi?id=91273#c7">comment #7</a>) > > I still don't understand what you mean by "the kernel may not wake up the > > thread" if it refers to a different issue than the two mentioned above. > > When A thread is polling on a display fd and B thread is polling on the same > display fd, if a server sends messages, sometimes only one thread(Let's say > it is B thread) awakes and reads all events so fast. Then A thread still is > in the polling status and can't awake. Even if B thread reads and queue all > events into corresponding queue_lists, the events of A thread's queue_list > can't be handled because A thread is still in sleep. All threads call wl_display_read_events() after returning from poll(), but only the last thread reads the data from the fd. That way we make sure all threads who called wl_display_prepare_read_queue() will come out of poll before we read the data. The kernel may only wake one thread, but that's only an optimization. If that thread doesn't read the data but goes to sleep on a pthread condition (the case for the n-1 first threads), the other threads that block on poll will eventually run and rendezvous in wl_display_read_events().</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>