4 ms·

A much cleaner and portable solution to the races triggered by duplicated and early signals is to set up a pipe and have signal handlers write the signal number

A much cleaner and portable solution to the races triggered by duplicated and early signals is to set up a pipe and have signal handlers write the signal number to that pipe. A write syscall is permitted in a signal handler and now you can (p)select/poll the signals like any other file descriptor

jwilk 3y ago
It's mentioned in the article: > There's also the classic self-pipe trick.
iforgotpassword 3y ago
And ideally, have a thread for that that you spawn in the beginning, then block signals on the main thread before spawning any other thread or initializing any library that might potentially do so.
- Joker_vD 3y ago
  I'll take "Things that the OS should probably be doing itself but instead we end up re-doing it in the userspace, poorly, for historical reasons" for 400, Alex.
  - pwdisswordfishc 3y ago
    It does. https://www.man7.org/linux/man-pages/man2/signalfd.2.html https://www.man7.org/linux/man-pages/man2/signalfd.2.html
    - marcosdumay 3y ago
      Why people still didn't deprecate signal handlers (except for 15)?
    - iforgotpassword 3y ago
      Obligatory https://ldpreload.com/blog/signalfd-is-useless?reposted-on-request https://ldpreload.com/blog/signalfd-is-useless?reposted-on-r... post. :) It's a divisive article, but I generally agree, saving you a thread is basically what it mostly does, and there's already enough boilerplate out there to do that. Plus you sacrifice portability.
      - Joker_vD 3y ago
        One of the root problems with the UNIX signals IMHO is that they conflate 3 different useful concepts together. The first concept is that of asynchronous external events that the process would like to react to in a timely manner (e.g. SIGINT): those can be processed on a dedicated thread, maybe it could be created anew every time a signal is delivered a la Windows [0], maybe it could be created once at the moment of execve and ELF format should get a "secondary entry point" field for it, whatever. The second concept is that of synchronous internal events that the process has caused itself (e.g. SIGSEGV, SIGILL): well, those are just low-level exceptions, and could be processed on the thread that caused them. Some sort of structural exception handling [1] (only less awkward) could work, I think? An interesting mix of those two kinds of signals is SIGALRM, which is an asynchronous internal event. Can be quite useful for implementing lighter-weighted/cooperative multitasking, I guess: it basically makes the OS to regularly punt your instruction pointer somewhere else where you could e.g. flush some memory and raise semaphores so a sibling thread could notice and report the progress to the user, while the main thread returns back to number crunching, or you could use it to to force coroutines/fibers to yield or something. To be fair, not sure what the proper interface for this should look like. And the third concept is that of the control operations acting on the process itself, the operations that the process gets no chance to react to: SIGKILL, SIGSTOP, SIGCONT. They are not really process signals, they are the API of the process manager/scheduler that were implemented with the signals machinery because what was the other choice? Introducing new system calls? [0] https://learn.microsoft.com/en-us/windows/console/handlerroutine https://learn.microsoft.com/en-us/windows/console/handlerrou... [1] https://learn.microsoft.com/en-us/windows/win32/debug/structured-exception-handling https://learn.microsoft.com/en-us/windows/win32/debug/struct...
deleted 3y ago
[deleted]

jwilk 3y ago

It's mentioned in the article: > There's also the classic self-pipe trick.

iforgotpassword 3y ago

And ideally, have a thread for that that you spawn in the beginning, then block signals on the main thread before spawning any other thread or initializing any library that might potentially do so.

Joker_vD 3y ago
I'll take "Things that the OS should probably be doing itself but instead we end up re-doing it in the userspace, poorly, for historical reasons" for 400, Alex.
- pwdisswordfishc 3y ago
  It does. https://www.man7.org/linux/man-pages/man2/signalfd.2.html https://www.man7.org/linux/man-pages/man2/signalfd.2.html
  - marcosdumay 3y ago
    Why people still didn't deprecate signal handlers (except for 15)?
  - iforgotpassword 3y ago
    Obligatory https://ldpreload.com/blog/signalfd-is-useless?reposted-on-request https://ldpreload.com/blog/signalfd-is-useless?reposted-on-r... post. :) It's a divisive article, but I generally agree, saving you a thread is basically what it mostly does, and there's already enough boilerplate out there to do that. Plus you sacrifice portability.
    - Joker_vD 3y ago
      One of the root problems with the UNIX signals IMHO is that they conflate 3 different useful concepts together. The first concept is that of asynchronous external events that the process would like to react to in a timely manner (e.g. SIGINT): those can be processed on a dedicated thread, maybe it could be created anew every time a signal is delivered a la Windows [0], maybe it could be created once at the moment of execve and ELF format should get a "secondary entry point" field for it, whatever. The second concept is that of synchronous internal events that the process has caused itself (e.g. SIGSEGV, SIGILL): well, those are just low-level exceptions, and could be processed on the thread that caused them. Some sort of structural exception handling [1] (only less awkward) could work, I think? An interesting mix of those two kinds of signals is SIGALRM, which is an asynchronous internal event. Can be quite useful for implementing lighter-weighted/cooperative multitasking, I guess: it basically makes the OS to regularly punt your instruction pointer somewhere else where you could e.g. flush some memory and raise semaphores so a sibling thread could notice and report the progress to the user, while the main thread returns back to number crunching, or you could use it to to force coroutines/fibers to yield or something. To be fair, not sure what the proper interface for this should look like. And the third concept is that of the control operations acting on the process itself, the operations that the process gets no chance to react to: SIGKILL, SIGSTOP, SIGCONT. They are not really process signals, they are the API of the process manager/scheduler that were implemented with the signals machinery because what was the other choice? Introducing new system calls? [0] https://learn.microsoft.com/en-us/windows/console/handlerroutine https://learn.microsoft.com/en-us/windows/console/handlerrou... [1] https://learn.microsoft.com/en-us/windows/win32/debug/structured-exception-handling https://learn.microsoft.com/en-us/windows/win32/debug/struct...

deleted 3y ago

[deleted]