[PATCH wayland] client: ensure thread safety for wl_display_roundtrip_queue()
Ucan, Emre (ADITG/SW1)
eucan at de.adit-jv.com
Tue Feb 16 10:46:11 UTC 2016
Hi Jonas,
What are the shortcomings of my approach ? Because we want to use this approach internally for thread safety.
If there are no shortcomings, is it not better to use this approach than introducing many new APIs ?
Best regards
Emre Ucan
Software Group I (ADITG/SW1)
Tel. +49 5121 49 6937
> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Jonas Ã…dahl
> Sent: Dienstag, 16. Februar 2016 04:49
> To: Ucan, Emre (ADITG/SW1)
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH wayland] client: ensure thread safety for
> wl_display_roundtrip_queue()
>
> On Mon, Feb 15, 2016 at 02:19:43PM +0000, Ucan, Emre (ADITG/SW1) wrote:
> > We have to block other threads from reading events. Otherwise other
> > threads may assign done event to the default queue, if they call
> > wl_display_read_events before setting the queue for the callback proxy.
> > This would cause a deadlock in wl_display_dispatch_queue, because the
> > default queue is not dispatched.
> >
> > We can call wl_display_prepare_read_queue API which blocks on success
> > other threads from reading events and call wl_display_cancel read
> > after the queue is set to the proxy. This new implementation ensures
> > thread safety for the API.
>
> This is the work-around available to avoid the issue, but it is not the correct
> solution for libwayland-client. Right now we have two potential
> solutions: one is to add a "proxy wrapper" where one configures the proxy
> wrapper object (setting the queue) before using it to issue requests, the
> other is to add thread safe functions and patch the scanner to add thread
> safe helpers which would be used instead of for example
> "wl_display_sync()".
>
> The proxy wrapper approach can be tested out by appling this patch:
> https://lists.freedesktop.org/archives/wayland-devel/2015-
> June/023054.html
>
> For more information, check the corresponding bug in bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=91273
>
>
> Jonas
>
> >
> > Signed-off-by: Emre Ucan <eucan at de.adit-jv.com>
> > ---
> > src/wayland-client.c | 16 +++++++++++++++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/wayland-client.c b/src/wayland-client.c index
> > ef12bfc..00d8cda 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c
> > @@ -1075,12 +1075,26 @@ wl_display_roundtrip_queue(struct wl_display
> *display, struct wl_event_queue *qu
> > struct wl_callback *callback;
> > int done, ret = 0;
> >
> > + /*We have to block other threads from reading events. Otherwise
> other threads
> > + * may assign done event to the default queue, if they call
> wl_display_read_events
> > + * before setting the queue for the callback proxy. This would cause a
> deadlock
> > + * in wl_display_dispatch_queue, because the default queue is not
> dispatched.*/
> > + while (ret >= 0 && wl_display_prepare_read_queue(display,
> queue))
> > + ret = wl_display_dispatch_queue_pending(display, queue);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > done = 0;
> > callback = wl_display_sync(display);
> > - if (callback == NULL)
> > + if (callback == NULL) {
> > + wl_display_cancel_read(display);
> > return -1;
> > + }
> > +
> > wl_proxy_set_queue((struct wl_proxy *) callback, queue);
> > wl_callback_add_listener(callback, &sync_listener, &done);
> > + wl_display_cancel_read(display);
> > while (!done && ret >= 0)
> > ret = wl_display_dispatch_queue(display, queue);
> >
> > --
> > 1.7.9.5
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list