Wayland Message Behaviour

[Pekka Paalanen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171110/5a92968e/attachment.sig>