3 ms·

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

• destructionator 4y ago
  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.
  • throwawaylinux 4y ago
    > 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.