Hacker News new | ask | show | jobs
by CyberDildonics 1613 days ago
Because it allows you to do lock free memory based interprocess communication, which can be extremely fast.
1 comments

There is no need for file-backed memory to do that.
Sounds good, what is your solution and why didn't you explain it in your first reply?
What is my solution to what? To database I/O? I guess that's what the article is about...
I said "lock free memory based interprocess communication"

You said "There is no need for file-backed memory to do that."

If that is true, I want to know what you are talking about, so I'm just asking you to back up the claim you made.

No. _I_ want to know what we're talking about, as my original question clearly indicates.

You can do "lock-free memory based interprocess communication" with memory (obviously). There is no need to back this memory with files, certainly not files on a hard drive that you would otherwise access using read() and write(). Hence my original question.

_I_ want to know what we're talking about

lock free memory based interprocess communication (copied from my first reply)

There is no need to back this memory with files

Again, I'm interested in how you have two processes read and write lock free directly to the same memory if you don't use a memory mapped file.

You have said it isn't necessary, I'm just asking you to back up this claim and explain exactly what you mean.