Hacker News Reader

Comment by chlorion | Hacker News Reader

None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop.

There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only.

Being asynchronous was an design goal for Wayland from the very beginning.

View on HN

This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)

What do you mean by all Wayland's calls being blocking though?

It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally, it is unlikely to matter. The time spent there is near zero anyway. But remotely, now you might be looking at several ms per iteration and that adds up fast. Now the blocking aspect can become problematic.

Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

> It isn't really Wayland's calls itself, I prolly stretched too much there,

Do you mean simply incorrect i.e., that Wayland calls are not all blocking? Or do you mean that in practice there are some important high-level situations that do require a round trip despite the low level purporting to be mostly asynchronous?

> Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

Wayland can run to remote displays though, right? You could argue it's not complete or well supported or nicely integrated into the core protocol or whatever, but you can literally use it today and probably have a package to do it available in any Linux distro you're using (e.g., waypipe). So it's hard to see what you're getting at. Wayland may not have been made with transparent networking support foremost in the protocol but AFAIK the idea was always that you'd be able to do remoting by forwarding buffer contents with the protocol.

Async X11 was tried with xcb, and it failed. In the above linked video, this is illustrated in the "Bad IPC" part, with the example of gedit startup (gedit uses gtk and gtk uses xcb) and where it blocks.

He claims gedit does 130 blocking InternAtom calls, 34 blocking GetProperty calls, and 116 property change requests. None of those are actually using the available async functions (or even available XInternAtoms call to batch all those 130 into the main thing).

Since this video is coming up on ten years old, it might have been true at the time, and gtk/gedit have since changed the implementation. But regardless, if the video is accurate, they didn't use the non-blocking calls. If the video is not accurate, it is meaningless anyway.

Reply on news.ycombinator.com