3 ms·
1. mmap was added to Unix later by Sun, it wasn't in the original Unix 2. As the article points out mmap is very fast for reading huge amounts of data but is a
by trenchpilgrim 1y ago
1. mmap was added to Unix later by Sun, it wasn't in the original Unix
2. As the article points out mmap is very fast for reading huge amounts of data but is a lot slower at other file operations. For reading smallish files, which is the majority of calls most software will make to the filesystem, the regular file syscalls are better.
3. If you're on a modern Linux you might be better off with io_uring than mmap.
- scottlamb 1y agoAll true, and it's not just performance either. The API is just different. mmap data can change at any time. In fact, if the file shrinks, access to a formerly valid region of memory has behavior that is unspecified by the Single Unix Specification. (On Linux, it causes a SIGBUS if you access a page that is entirely invalid; bytes within the last page after the last valid byte probably are zeros or something? unsure.) In theory I suppose you could have a libc that mostly emulates read() and write() calls on files [1] with memcpy() on mmap()ed regions. But I don't think it'd be quite right. For one thing, that read() behavior after shrink would be a source of error. Higher-level APIs might be more free to do things with either mmap or read/write. [1] just on files; so it'd have to track which file descriptors are files as opposed to sockets/pipes/etc, maintaining the cached lengths and mmap()ed regions and such. libc doesn't normally do that, and it'd go badly if you bypass it with direct system calls.
- nawgz 1y agoInteresting callouts! Thanks
- deleted 1y ago[deleted]