logoalt Hacker News

nananana9yesterday at 9:53 PM3 repliesview on HN

Yes, command buffers over shared memory are the correct way to do this.

  1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side.
  2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back.
  3. You don't need to deal with the "oh but what if my read returns half a message because this is a stream"
  4. You don't need to pretend you're doing network programming.
Regardless, it's not that big of a deal - this is like my 73th biggest gripe with Wayland, I only mentioned it since GP was talking about network transparency.

It's pretty representative of the project though - "We're doing things the way we've always done them, but slightly different. Now rewrite all your software to work with our thing. No, you cannot do global keyboard shortcuts or set window position. You don't like it? We're doing this for free, you cannot critique it."


Replies

mike_hocktoday at 5:10 AM

> command buffers over shared memory are the correct way to do this

Sounds like a security nightmare.

mort96yesterday at 9:57 PM

You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that in userspace code.

You need some kind of serialisation either way. It can be as simple as “this message has the shape of this C struct”, but that’s the case whether you’re talking shared memory command buffers or sending data over a socket (and there are good arguments for and against in both cases).

You’re right that you don’t need to deal with “oh I received half a message” when using shared memory command buffers, but that’s more a code complexity thing someone solves once in wayland-client and then nobody has to really think about it again. It’s not really a performance concern (because hopefully the rx buffer is large enough for it to happen rarely) or application code complexity concern.

show 1 reply
asdfaoeuyesterday at 10:02 PM

You would have a lot of security issues right? Whether or not it's useful Wayland does prevent to isolate clients from each other.

show 2 replies