Wayland Message Behaviour

[Turner, LewisX]

Hi Derek and pq,

Thanks for the further suggestions and comments.

The idea around multiple threads is a likely candidate. We have added a thread and the flush is coming from the extra thread.

There seems to be two obvious approaches to solving the issue:
1) Create a new queue for our new thread and just flush the new queue.
2) Signal back to the main thread to request that the queue is flushed.

Do you have any advice/opinion on which approach might be better? Are there any examples of taking either approach?

Regards,
Lewis

-----Original Message-----
From: wayland-devel [mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of Pekka Paalanen
Sent: Friday, November 10, 2017 8:29 AM
To: Derek Foreman <derekf at osg.samsung.com>
Cc: Turner, LewisX <lewisx.turner at intel.com>; wayland-devel at lists.freedesktop.org
Subject: Re: Wayland Message Behaviour

On Thu, 9 Nov 2017 10:59:27 -0600
Derek Foreman <derekf at osg.samsung.com> wrote:

> On 2017-11-08 10:02 AM, Turner, LewisX wrote:
> > Hi all,
> > I have come across some strange behavior with Wayland and I wondered 
> > if you could share your thoughts on it.

I would probably have never thought of the possibility of threads in the server... thanks, Derek.

> > Also, when this happens it’s worth nothing that 
> > wl_display_roundtrip() reports an error, and wl_display_get_error() 
> > returns an error code. The documentation online suggests errors here 
> > are fatal and we cannot use the display again.
> > Also note that commenting out the call to wl_client_flush() makes 
> > the issue go away. However, we then see an unacceptable delay before 
> > the event is received on the client side.
> 
> I've seen client side stalls related to libraries dispatching their 
> own queues, which reads everything from the wayland connection into a 
> buffer so the file descriptor is no longer flagged readable upon 
> entering select().  (mesa does this, it's perfectly acceptable library 
> behavior)
> 
> That would be easily fixed by calling wl_display_dispatch_pending() 
> before calling select() in the client.

Even better would be to make sure all the client side code that deals with the Wayland fd or dispatches messages uses the
wl_display_prepare_read() sequence:

https://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0
(doc link to wl_display_prepare_read_queue())

A client developer should also always keep in mind that you always need a new wl_event_queue for each thread that dispatches events. You probably do need a separate wl_event_queue for every dispatching context anyway. Dispatching the same queue from several places often leads to complicated consequences.

The above is especially important to remember when calling wl_display_roundtrip(), because that is a dispatching function. IOW, it should probably never be called once the client enters its main event loop.

The above concerns libwayland-client, which has limited multithreading support. OTOH, libwayland-server is not at all thread-safe, aside from never using static data.

But I digress.

> > The main question at this point is whether anyone else has seen 
> > similar behavior. We do not want to spend more time investigating 
> > this if the cause is a known issue.
> 
> Never seen anything quite like this, no.  I don't think you're seeing 
> a known bug.
> 
> strace might be useful in determining if you're actually seeing the 
> compositor send the event twice (and determine if it's twice from the 
> same write vs two independent writes), as well as seeing if the client 
> received it twice or processed it twice...

A middle-man protocol dumper I referred to earlier would also show this, I think.


Thanks,
pq
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928