4 ms·

> 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 p

by c00lio 3y ago

> 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 https://man7.org/linux/man-pages/man7/shm_overview.7.html

ori_b 3y ago
It can have a name in the file system: /dev/shm
marcosdumay 3y ago
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.
- plorkyeran 3y ago
  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.
- totony 3y ago
  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
  - marcosdumay 3y ago
    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.

by c00lio 3y ago

ori_b 3y ago

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

marcosdumay 3y ago

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.

plorkyeran 3y ago
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.
totony 3y ago
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
- marcosdumay 3y ago
  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.