Difficulties With Unix Signals

This is a list of problems with Unix signals. Some of them are semantic problems (e.g. with threading), but some are just issues with a bad API and unclear ideas about what is portable.

• Signals and multithreading
  • This blog post and related comments are show much confusion there are: signalfd is useless. The author retracted his main point, saying that signalfd can still save you a thread.
  • After PEP 475, the Python interpreter special cases EINTR (ignores it) on dup2() and close()
    • The basic reason is that those two system calls change the descriptor table, and in a multi-threaded context that leads to a race condition if you have a while (1) retry loop.
    • https://lwn.net/Articles/576478/
• Job Control: Interaction between signals and terminals (??)
  • There are a whole bunch of special syscalls for job control that I don't fully understand.
  • libc: Implementing a Job Control Shell
• In Interpreters: Signal Handling Can Be Arbitrarily Delayed
  • Any nontrivial logic must be run on the main thread, not in the signal handler. So interpreters queue signal handlers for running on the main loop. (I think bash only changed this recently, but Python has always done this.)
  • A single Python bytecode can take arbitrarily long (i.e. running a long computation in C). This means that signal handling can get arbitrarily delayed. Is it a problem in practice?
• API Usability Issues
  • Signals can be coalesced. e.g. When you get SIGCHLD, you have to call os.wait() multiple times to get multiple notifications. What about other signals?
    • Signals are coalesced for interpreters as well
  • Simultaneously waiting for both a signal and an event on a file descriptor. Solution: "the self-pipe trick". (Although there are some possible drawbacks listed on the "signalfd is useless" thread.)
  • When a program starts to handle signals, now it must explicitly handle EINTR (in C, Python 2.7, although PEP 475 changed this).
• Signals don't compose !
  • Can I run xargs as a builtin inside shell (i.e. in the same process)? It has to deal with signals. Maybe a bigger issue is that the wait() logic is complicated?
  • Similar issue: Do I need a "dummy process" for the Coprocess-Protocol-Proposal ? This is related to the self-pipe trick, because with a coprocess, a "process exit" turns into a file descriptor event.
  • What about timeout as a builtin?

Related

• Signal Handling in Oil