https://bugs.freedesktop.org/show_bug.cgi?id=91750
--- Comment #10 from Jonas Ådahl <[email protected]> --- (In reply to Yujie Shen from comment #9) > (In reply to Jonas Ådahl from comment #8) > > (In reply to Yujie Shen from comment #7) > > > > It is a requirement by wl_display_prepare_read_queue() that to succeed the > > queue has to be empty and it needs to succeed in order to block the other > > threads from dispatching. You should put it before wl_surface_frame() > > though, because it is between wl_surface_frame() and wl_proxy_set_queue() > > the race can happen, and don't forget to call wl_display_cancel_read(). > > > > Earlier today I wrote a summary about the known threading issues in the API. > > Please see bug 91769. > Thanks. > I know it is a requirement by wl_display_prepare_read_queue() . > I mean why it is designed as that, only the queue is empty then it block the > other > threads from dispatching. It seems that wl_display_prepare_read_queue can > also be designed as it still can block other threads from dispatching when > the queue is not empty. I can't remember if any reason has been explicitly mentioned, but considering the regular use case (not this work around) where one is expected to actually poll() the fd and then read and dispatch events, one should dispatch the already queued events *before* starting to wait indefinitely for new input. The empty-queue requirement enforces the caller not to leave events ready for dispatching in the queue indefinitely. -- 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
