Hacker News Reader

Comment by marcosdumay | Hacker News Reader

> write(SIGKILL, "/proc/12345/signals")

Outside of lots of non-obvious problems with synchronization, this is your example that best fits the idea. This interface is probably a good one.

> And of course you can get a peer address from /dev/tcp

You will have lots and lots of problems with access controls if this is your only interface.

> Shared memory can be a file

Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

View on HN

> Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

The file doesn't need to have an on-disk representation. I don't see why an mmap-ed file should behave any different from a SHM segment. They are basically the same thing, the SHM segment even has a file descriptor. It just doesn't have a name somewhere in the filesystem hierarchy. https://man7.org/linux/man-pages/man7/shm_overview.7.html

To reverse that question, what do you gain by defining a `read` and `write` API over that memory segment?

Because if you just add some high-level interface without any concern for performance, yeah, you get what Linux does today. But if you make them a core concern of your shared memory interface, you will certainly lose performance on the cases it's mapped as memory. And "everything is a file, but this one here is actually all about random access" doesn't give you much abstraction.

As somebody already said on the comments, the nice (maybe IMO, I'm not sure) thing about Plan9 is that every resource is named somewhere in a tree. The fact that those things are "files" only detracts from the value and makes the system less fit for modern usage.

Yeah, "everything has a filename" and "everything is a file" are very similar concepts but they aren't quite the same, and it might be that most of the value comes from the former.

Having a cursor to access files is mostly legacy no? The difference between memory and storage is getting very small, e.g. ssds and optane

Not exactly legacy, as SSDs are not completely random access, and disks still exist. But yes, the stream abstraction is losing relevance for files.

But well, if the proposal is to unify everything, you will have to unstream network connections too.

It can have a name in the file system: /dev/shm

> This interface is probably a good one.

This interface is a bad one because if you want to filter syscalls then it will be difficult to distinguish write to a file from sending a signal.

You will filter syscalls by filename anyway.

Try `strace|grep open` on any program, and you will be spammed with a number of shared libraries. You need to filter them out anyway.

Reply on news.ycombinator.com