Hacker News Reader

Comment by Shivetya | Hacker News Reader

How is this different than IBM's single store model? Memory and disk are addressed as one with hardware providing the protection needed in case of component or system failure.

Unless your writing at the machine level I really do not see the need for most programmers to ever concern themselves with storage, that should be the work of the underlying machine code and/or OS.

View on HN

if ram and permanent storage becomes the same, in instance, you wont need to "open(" a file, just to point to the memory location of it.

Is that fundamentally different from http://en.wikipedia.org/wiki/Memory-mapped_file ?

I was just thinking about this the other day. Yes, a memory-mapped-file is different, because the API is still that of a file. The memory mapping is just a behind-the-scenes optimisation.

Only if you want posix compliance across threads and such. If you just want the contents of the file memory mapped nothing stops you from setting up a shared memory segment and mapping it without that filesystem overhead.

Does that work for writes as well? I am not sure if it would work without the OS setting up traps for writes to the pages or explicit flush calls from the app. In the former case, it would be very inefficient, and in the latter, it wouldn't be a clean write-and-forget system.

Yes, it works for writes and support is built-in to current processors. It's faster than conventional file access.

That's how the AS/400 works.

Reply on news.ycombinator.com