Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

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)



> 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?


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_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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: