3 ms·

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 bet

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.
    - wahern 7y ago
      > Mixing signals and threads is pretty much trash. Agreed, except for SIGSEGV, SIGBUS, and SIGPIPE, which are guaranteed to be delivered, if at all, to the thread which triggered the condition. (Unless, of course, they were raised explicitly.) Still trash in the sense that to do it right you're depending on installing global signal handlers and (very likely) arranging for thread-local storage (actual TLS isn't even async-signal safe; see my post elsethread regarding the sigaltstack trick), so these tricks are really only practical for the core application and not something you can stash in a library to perform transparently. FWIW, none of this behavior is specific to Linux. Linux follows POSIX rather well in this regard.

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.
  - wahern 7y ago
    > Mixing signals and threads is pretty much trash. Agreed, except for SIGSEGV, SIGBUS, and SIGPIPE, which are guaranteed to be delivered, if at all, to the thread which triggered the condition. (Unless, of course, they were raised explicitly.) Still trash in the sense that to do it right you're depending on installing global signal handlers and (very likely) arranging for thread-local storage (actual TLS isn't even async-signal safe; see my post elsethread regarding the sigaltstack trick), so these tricks are really only practical for the core application and not something you can stash in a library to perform transparently. FWIW, none of this behavior is specific to Linux. Linux follows POSIX rather well in this regard.