<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - Wayland may have interface bug when multi-threads programing." href="https://bugs.freedesktop.org/show_bug.cgi?id=91750#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - Wayland may have interface bug when multi-threads programing." href="https://bugs.freedesktop.org/show_bug.cgi?id=91750">bug 91750</a> from <a class="email" href="mailto:syjman@gmail.com" title="Yujie Shen <syjman@gmail.com>"> Yujie Shen</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=91750#c8">comment #8</a>) > (In reply to Yujie Shen from <a href="show_bug.cgi?id=91750#c7">comment #7</a>) > > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=91750#c6">comment #6</a>) > > > Yujie: as indirectly stated by Pekka, my example was incomplete. You would > > > also need to dispatch pending events before the > > > wl_display_prepare_read(display) call. This makes it, ignoring error > > > handling, more or less: > > > > > > wl_surface_attach(); > > > while (wl_display_prepare_read_queue(display, queue) < 0) > > > wl_display_dispatch_queue_pending(display, queue); > > > window->callback = wl_surface_frame(window->surface); > > > wl_proxy_set_queue(window->callback,queue2); > > > wl_callback_add_listener(window->callback, &frame_listener, window); > > > wl_display_cancel_read(display); > > > wl_surface_commit(window->surface); > > > > > > This has the side effect that events already in the queue will be always > > > dispatched before the frame is requested. This may have unwanted effects, so > > > please consider whether this is Ok in your architecture. If it is not, you > > > need to make sure that the above code is done after all events on the queue > > > has been dispatched. > > > > Thanks for your kindly help. > > By adding > > >while (wl_display_prepare_read_queue(display, queue2) < 0) > > > wl_display_dispatch_queue_pending(display, queue2); > > >wl_surface_commit(window->surface); > > it works in my case. > > but, I still don't understand why it requires the wl_event_queue to be > > empty?? > > I'm trying to summary the restrictions of wayland when multi-thread > > programming. > > May I know if you have any idea about it. > > 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 <a class="bz_bug_link bz_status_NEW " title="NEW - Meta bug for libwayland-client threading issues" href="show_bug.cgi?id=91769">bug 91769</a>. 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>