[jstimpfle]

> There is no need to back this memory with files

And there isn't. It seems you just don't really understand virtual memory, and don't want to acknowledge what everyone else understands by "file-backed memory". And given that I find it courageous how stubborn you are, as well as starting personal attacks.

> Then you wouldn't explain it and eventually admit that you do need to have a file path

Need to have a file path IN WHICH ENVIRONMENT, IN WHICH CONTEXT??? Could YOU please clarify. We can easily make a simple OS which doesn't have "files" but does have processes that can share memory using virtual memory technology.

Shared memory IPC is fundamentally not about files, and you were even shown a way to setup shared memory mappings between Linux processes using normal userland API entirely without the use of files or file paths - with the restriction that the mappings have to be inherited (fork()).

How someone, even with no real understanding of the topic, could not at the latest at https://news.ycombinator.com/item?id=29947339 acknowledge that I was being perfectly clear that I was talking about persistent files (I literally said on a hard drive), is beyond me. I should have stopped this discussion at that point.

Now get off my lawn.

[CyberDildonics]

Files being persistent on storage has nothing to do with communicating through shared memory. It isn't necessary and it doesn't interfere if it's there. It is completely orthogonal, I don't know why it would ever be a part of the conversation when talking about direct reading and writing to the same memory.

[jstimpfle]

> Files being persistent on storage has nothing to do with communicating through shared memory.

Files (whether persistent or not) have not really anything to do with communication through shared memory. In the implementation of an API like shm_open(), the VFS (virtual filesystem) is simply the address space and lookup mechanism that an operating system like Linux happens to use in order to find the memory that should be shared.

> It isn't necessary and it doesn't interfere if it's there.

Sure it does interfere. By backing memory needlessly with a persistent file, you're causing disk I/O from the loading and flushing (that can't really be controlled) and potentially bad performance.

Also, as explained, if you use a persistent file to track the synchronization state, the synchronization state won't be reset when the communicating processes die unexpectedly, and this might be problematic.

[CyberDildonics]

system like Linux happens to use in order to find the memory that should be shared.

Right. Is there some other mechanism to coordinate mapping the same memory between processes? That's all I ever asked.

Sure it does interfere. By backing memory needlessly with a persistent file, you're causing disk I/O from the loading and flushing (that can't really be controlled) and potentially bad performance.

That is orthogonal, since once you have the memory mapped into both processes you can use atomics for lock free IPC. That's the whole thing. It doesn't matter what the OS does or doesn't do in the background, atomically reading and writing to memory is unaffected.

[jstimpfle]

Why are you constantly ignoring what I'm writing?

> It doesn't matter what the OS does or doesn't do in the background, atomically reading and writing to memory is unaffected.

That's not true. If this thing is file backed there is usually no guarantee that the page of virtual memory (i.e. a page of the file data) you're accessing is present in physical memory. You'll cause page faults and data transfers to/from disk. This can delay the execution of an atomic read or write potentially infinitely, or even cause a "crash" of some kind if the disk transfer fails.

You can avoid the page faulting part of this if you somehow pin the memory. Which is completely ridiculous given that all you ever wanted is anonymous memory. I've looked up a website that seems to explain this better (but I haven't checked it deeply). Maybe it helps: https://eric-lo.gitbook.io/memory-mapped-io/pin-the-page

[CyberDildonics]

This can delay the execution of an atomic read or write

You can play "what if" all you want if you don't know what else running, but this was always about lock free interprocess communication, which is not broken by a page fault or process suspension.

An atomic instruction by design will do everything it needs to when the instruction runs.

Saying the OS can ultimately control the execution of a process is a nonsense cop out to try to skew away from the original point.

all you ever wanted is anonymous memory

This is local to a process tree and does not work for interprocess communication.

[jstimpfle]

Dude, the example I gave you with shm_open() is creating anonymous memory. That's just what non-file-backed mappings are called, no matter how long you want to keep obsessing about any "file paths".