5 ms·

Alternatively one can run a separated process that does mmap and runs the calculations or whatever that needs to access the file as quickly as possible and do

Alternatively one can run a separated process that does mmap and runs the calculations or whatever that needs to access the file as quickly as possible and do the the straightforward recovery in the parent process when the child process dies. The drawback is the need to some form of RPC, but there a lot of libraries to do that without much hustle.

quotemstr 7y ago
You can do that with a MAP_ANONYMOUS | MAP_SHARED mapping too: that kind of mapping is writable by both parent and child, but isn't backed by a disk file and so can't be truncated or surprise-removed. The article's points about mmap infelicity applies mostly to mappings of disk files. Anonymous mappings don't have the same problems.
- tus87 7y ago
  Yes, but if the file is on local disk its exactly the same situation as the page file. OP seems to be trying to cope with NFS errors....but if you are using mmap on NFS you have bigger problems...
- 0db532a0 7y ago
  The article points out the infelicity as applied to mappings of files into multi-threaded programmes. What fpoling suggests is a solution to the POSIX signals problem where anonymous mmaps are not an option.
- _wmd 7y ago
  Anonymous mappings are backed by swap and may be overcommitted, it's still possible to catch signals in a wide variety of circumstances There is probably enough evidence in this thread to use it as a reference for why typical apps should avoid mmap whenever possible -- it's clear almost nobody fully understands it
  - gpderetta 7y ago
    > Anonymous mappings are backed by swap and may be overcommitted, So is normal memory. Many allocators today even use mmap internally.
    - deleted 7y ago
      [deleted]
    - quotemstr 7y ago
      All* allocation is mmap, really. All mmap does is dedicate a region of address space to some kind of backing storage. The particular kind of backing storage makes all the difference. The problem is that people colloquially use "mmap" to mean "mmap of a conventional disk file" and don't mean all the other kinds of mmap out there, so discussions can become confusing. * Ther's sbrk too, but it's just a fancy legacy path that amounts to the same thing as anonymous mmap
  - klodolph 7y ago
    > Anonymous mappings are backed by swap and may be overcommitted, it's still possible to catch signals in a wide variety of circumstances Anonymous mappings won't cause signals, they'll trigger the OOM killer. Remember that malloc() is just a fancy wrapper for mmap() (and sbrk()).
    - _wmd 7y ago
      If a process was swapped out and a fault fails to bring a page back due to an IO error, you can at least catch (I think) SIGBUS. But this just reinforces the point: nobody really understands virtual memory, even people like us that think they do
      - klodolph 7y ago
        Okay, but I'd say the correct thing to do is let SIGBUS kill the process. You can at least expect to handle SIGBUS for a file you've mapped.
      - 7y ago
arethuza 7y ago
I guess if you are using RPC you could forget about NFS and just run your "editor server" on the server where the file is actually stored :-)
- majewsky 7y ago
  In many cases, the server where the file is actually stored will not allow you to execute random code.
blattimwind 7y ago
If you are already copying things around (between address spaces even), you might as well just use pread or lseek+read, which at that point is likely a much better choice overall.
- saagarjha 7y ago
  Couldn’t you mmap a shared, read-only page so that your OS doesn’t copy it?
  - jschwartzi 7y ago
    It would be better to mmap the file into N single-threaded processes instead of mmapping the file into 1 N-threaded process. This is exactly why signals are process-global instead of thread-local. The intent is that they were used for inter-process communication. The whole notion of processes and signals predates the notion of a thread, and threads are essentially a performance optimization for 30 or 40 year old hardware. If you use single-threaded processes then all of the processes can MAP_SHARED map the file and then they all get access to the file contents as each process is updating the file. And they all also have their own address space and can crash separately from each other.
    - beat 7y ago
      That's because mmap() predates multithreading (at least as a usable production approach rather than a lab experiment). It's best for IPC, not sharing between threads. I forget sometimes that the young'ns never grew up in a world without threads, and often never learned how unix really works.
    - knome 7y ago
      >This is exactly why signals are process-global instead of thread-local. Signals can be sent either to a process or to a specific thread under linux. Signals sent to the process are handled by an arbitrary thread. There's a bunch of gotchas and whatnot past that. Mixing signals and threads is pretty much trash.

quotemstr 7y ago

You can do that with a MAP_ANONYMOUS | MAP_SHARED mapping too: that kind of mapping is writable by both parent and child, but isn't backed by a disk file and so can't be truncated or surprise-removed. The article's points about mmap infelicity applies mostly to mappings of disk files. Anonymous mappings don't have the same problems.

tus87 7y ago
Yes, but if the file is on local disk its exactly the same situation as the page file. OP seems to be trying to cope with NFS errors....but if you are using mmap on NFS you have bigger problems...
0db532a0 7y ago
The article points out the infelicity as applied to mappings of files into multi-threaded programmes. What fpoling suggests is a solution to the POSIX signals problem where anonymous mmaps are not an option.
_wmd 7y ago
Anonymous mappings are backed by swap and may be overcommitted, it's still possible to catch signals in a wide variety of circumstances There is probably enough evidence in this thread to use it as a reference for why typical apps should avoid mmap whenever possible -- it's clear almost nobody fully understands it
- gpderetta 7y ago
  > Anonymous mappings are backed by swap and may be overcommitted, So is normal memory. Many allocators today even use mmap internally.
  - deleted 7y ago
    [deleted]
  - quotemstr 7y ago
    All* allocation is mmap, really. All mmap does is dedicate a region of address space to some kind of backing storage. The particular kind of backing storage makes all the difference. The problem is that people colloquially use "mmap" to mean "mmap of a conventional disk file" and don't mean all the other kinds of mmap out there, so discussions can become confusing. * Ther's sbrk too, but it's just a fancy legacy path that amounts to the same thing as anonymous mmap
- klodolph 7y ago
  > Anonymous mappings are backed by swap and may be overcommitted, it's still possible to catch signals in a wide variety of circumstances Anonymous mappings won't cause signals, they'll trigger the OOM killer. Remember that malloc() is just a fancy wrapper for mmap() (and sbrk()).
  - _wmd 7y ago
    If a process was swapped out and a fault fails to bring a page back due to an IO error, you can at least catch (I think) SIGBUS. But this just reinforces the point: nobody really understands virtual memory, even people like us that think they do
    - klodolph 7y ago
      Okay, but I'd say the correct thing to do is let SIGBUS kill the process. You can at least expect to handle SIGBUS for a file you've mapped.
    - 7y ago

arethuza 7y ago

I guess if you are using RPC you could forget about NFS and just run your "editor server" on the server where the file is actually stored :-)

majewsky 7y ago
In many cases, the server where the file is actually stored will not allow you to execute random code.

blattimwind 7y ago

If you are already copying things around (between address spaces even), you might as well just use pread or lseek+read, which at that point is likely a much better choice overall.

saagarjha 7y ago
Couldn’t you mmap a shared, read-only page so that your OS doesn’t copy it?
- jschwartzi 7y ago
  It would be better to mmap the file into N single-threaded processes instead of mmapping the file into 1 N-threaded process. This is exactly why signals are process-global instead of thread-local. The intent is that they were used for inter-process communication. The whole notion of processes and signals predates the notion of a thread, and threads are essentially a performance optimization for 30 or 40 year old hardware. If you use single-threaded processes then all of the processes can MAP_SHARED map the file and then they all get access to the file contents as each process is updating the file. And they all also have their own address space and can crash separately from each other.
  - beat 7y ago
    That's because mmap() predates multithreading (at least as a usable production approach rather than a lab experiment). It's best for IPC, not sharing between threads. I forget sometimes that the young'ns never grew up in a world without threads, and often never learned how unix really works.
  - knome 7y ago
    >This is exactly why signals are process-global instead of thread-local. Signals can be sent either to a process or to a specific thread under linux. Signals sent to the process are handled by an arbitrary thread. There's a bunch of gotchas and whatnot past that. Mixing signals and threads is pretty much trash.