4 ms·

DJB's self pipe trick solves the awkwarness of #4 -- waiting for a process exits plus other events non-deterministically: https://cr.yp.to/docs/selfpipe.html h

by chubot 4y ago

DJB's self pipe trick solves the awkwarness of #4 -- waiting for a process exits plus other events non-deterministically: https://cr.yp.to/docs/selfpipe.html https://cr.yp.to/docs/selfpipe.html FWIW a shell is basically two alternating, non-overlapping event loops: - a select() loop on the input terminal FD for getting keystrokes (e.g. GNU readline) - the waitpid(-1) loop for running code, i.e. get the next process that exited It never actually does both at the same time -- it doesn't wait for processes and stream input simultaneously, which is awkward without the self-pipe trick. --- Regarding adversarial processes, yes you need something like Linux cgroups to solve that problem. In traditional Unix, a process that can run arbitrary code can always escape your attempts to kill it. IIRC you can start a Linux process in a freezer cgroup, and stop everything in the cgroup. I recall reading the docs for an HPC platform that does that, and I'm sure Docker does it in some way too. --- I'd be interested in where `supervise` is used in production ... it seems like there is a bigger story behind this article! (copy of lobste.rs comment)

teddyh 4y ago
> It never actually does both at the same time -- it doesn't wait for processes and stream input simultaneously Couldn’t you use a signalfd to receive the SIGCHLD, and listen to both the terminal and signalfd at the same time?
- chubot 4y ago
  So there was a correction here, zsh and fish do wait for processes in the interactive part, but apparently not bash/dash/mksh: https://lobste.rs/s/om32da/unix_process_api_is_unreliable_unsafe#c_amz4g4 https://lobste.rs/s/om32da/unix_process_api_is_unreliable_un... As far as your question, shells don't use signalfd() because it's Linux-only! Most shells predate not just signalfd(), but Linux itself :) I wouldn't use it in a newer shell for portability. If it ever came up, I probably I would use the self-pipe trick. BTW I think there was some argument awhile ago that signalfd() is actually quite bad in the presence of threads, but a shell doesn't have threads so that doesn't matter.
  - teddyh 4y ago
    > but apparently not bash In bash, try “set -o notify” (same as “set -b”). This will turn on immediate notification of terminations of subjobs. So it’s not that bash lacks support for it, it’s that bash wants to be compatible with old Unix shells, but offers other behavior as an option.

by chubot 4y ago

teddyh 4y ago

> It never actually does both at the same time -- it doesn't wait for processes and stream input simultaneously Couldn’t you use a signalfd to receive the SIGCHLD, and listen to both the terminal and signalfd at the same time?

chubot 4y ago
So there was a correction here, zsh and fish do wait for processes in the interactive part, but apparently not bash/dash/mksh: https://lobste.rs/s/om32da/unix_process_api_is_unreliable_unsafe#c_amz4g4 https://lobste.rs/s/om32da/unix_process_api_is_unreliable_un... As far as your question, shells don't use signalfd() because it's Linux-only! Most shells predate not just signalfd(), but Linux itself :) I wouldn't use it in a newer shell for portability. If it ever came up, I probably I would use the self-pipe trick. BTW I think there was some argument awhile ago that signalfd() is actually quite bad in the presence of threads, but a shell doesn't have threads so that doesn't matter.
- teddyh 4y ago
  > but apparently not bash In bash, try “set -o notify” (same as “set -b”). This will turn on immediate notification of terminations of subjobs. So it’s not that bash lacks support for it, it’s that bash wants to be compatible with old Unix shells, but offers other behavior as an option.