Fixing Ctrl+C in Rust terminal apps: Child process management
fiveonefour.com
fiveonefour.com
You're also missing the standard techniques for managing and reaping your children, which I don't see mentioned. You don't need to maintain a registry of child processes for example, at least on Linux there are a few things you can do for this without any global state (PR_SET_PDEATHSIG, PR_SET_CHILD_SUBREAPER, PID namespaces). On MacOS you can write a routine to reap children like a linux init() process would. The registry approach is also fragile: what if library code spawns children?
Also, if the terminal is in raw mode then you'll never get ctrl+C. This is really about signal handling. You also can't gracefully shutdown if you get a SIGKILL, which is why PR_SET_PDEATHSIG and PID namespaces are very nice - they guarantee descendants get killed.
The process/thread/task won't receive SIGINT, true. But I believe it will see the character ETX (ASCII 3). Programs that use raw mode input need to do their own keystroke processing.
foo |head -n2
I also long for a more misuse-resistant terminal but that seems like a bigger problem.
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
sleep(1);
printf("after parent died!\n");
return 0;
}
return 0;
}
Standard output are just file descriptors with the number 0, 1, and 2, and you can use the dup2 syscall to assign those numbers to some pipes that you originally created before you fork. Now the standard output of your child process is going to those pipes in your parent process. Or you can close those file descriptors, which will prevent the child process from reading/writing them at all. Or you can do nothing, and the copied file descriptors from the parent still apply.
Conceptually, you think of "spawning a child" as something that is in some kind of container (the parent process), but the underlying mechanics are not like this at all, and processes don't actually exist in a "tree", they just happen to keep a record of their "parent process ID" so the OS knows who to notify when the process dies.
That is not quite right either, the newly created child processes generally go to the same process group as the parent, the process groups (and sessions) forming those "containers".
Tbh this is one of the many murky areas of UNIX.
kill -9 is sending a SIGKILL signal which, well, kills the program immediately.
(But as for barely… if you don’t run JS, then you just don’t see the code snippets, because for some inscrutable reason, unlike the rest of the document, they’re only rendered client-side.)
fruit flies like a banana.
So in reality this is just an incorrect sentence. It should be written as
"The horse that raced past the barn fell"
But it’s not incorrect to say
The tree grown tall is the one I planted
The horse raced past had somewhere to go
It’s easier to read
The tree grown tall last year withered
You can artificially push out the point at which the sentence disambiguates between whether the word is past tense or past particle, and make it seem that it’s probably past tense until it can’t be.
You could say that the sentence is LL(k) for an unintuitively high k.
> Unlike non-scoped threads, scoped threads can borrow non-'static data, as the scope guarantees all threads will be joined at the end of the scope.
> All threads spawned within the scope that haven’t been manually joined will be automatically joined before this function returns.
The fact Rust actually has scoped threads is unrelated, in Rust they can do this because they have working lifetime checking and in C++ such a feature would be meaningless, you're always assumed to have manually ensured the correct lifetimes and they aren't checked.
Generously you could say they're gesturing at the fact C++ decided to bolt the stop flag mechanic to jthreads, so you can have the old broken threads or this newer non-broken threads which also has built-in stop flags. But that's less choice, it's not as though you can't have a stop flag in Rust.