https://bugs.freedesktop.org/show_bug.cgi?id=91273
--- Comment #8 from Jonas Ådahl <[email protected]> --- (In reply to Boram from comment #7) > > 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. When the API is used correctly, all threads will have exited the poll() call and either canceled the read, or entered the read phase, so the scenario you describe won't happen. Note that no thread will ever read from the fd until *all* threads that called prepare_read has either called cancel_read or read_events. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
