[Wayland-bugs] [Bug 91750] Wayland may have interface bug when multi-threads programing.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91750

--- Comment #10 from Jonas Ådahl <jadahl at gmail.com> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150827/3bb83d1d/attachment-0001.html>