On Thu, 9 Nov 2017 10:59:27 -0600 Derek Foreman <der...@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
pgpFBsyXsJvim.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
