The graceful shutdown stuff is good, but always piping the output of child processes is not necessarily the right thing to do. Some processes need stdin (what if it's a shell?) and some processes will be checking if stdout is a tty. What you should do (and Rust doesn't make this easy) is allocate a new pty for your child processes if your own stdout is a tty. Some programs default to this (eg: ssh), others make it configurable (eg: docker).
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.
>Also, if the terminal is in raw mode then you'll never get ctrl+C.
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.
I’ve definitely seen all of these problems in Rust programs but they certainly aren’t limited to Rust programs. I do think it would be nice if Rust libraries were a bit more misuse-resistant when it came to preserving a coherent terminal.
I also long for a more misuse-resistant terminal but that seems like a bigger problem.
I hate to be the guy, but I could barely see the code snippets. Is contrast an issue for anyone else? Reader mode improves thins slightly but at the cost of code being unhighlighted and wrapping like crazy.
Yes, the contrast of the code examples is not great. Grey on grey, light pastels and orange does not combine into an easy-to-read color palette for me.
Child processes are created using, generally, 2 syscalls: fork, then exec. When you fork, all file descriptors the main process has open are copied, and are now open in two places. Then, when the child calls exec (to transform itself into the target program), all file descriptors stay open in the new process (unless a specific fd is explicitly configured otherwise, FD_CLOEXEC).
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.
fork() when followed by exec*() is generally inefficient. That's why vfork(), clone(), and clone3() exist. There's no point in duplicating (even CoW) the entire kernel side and libc internal state of a process if it's going to be replaced with exec*() by a new, unrelated process.
fd's don't inherently belong to a process, and indeed there are several ways of asking the kernel to pass an fd to another process.
stdin/out/err is just a shorthand (well, longhand) for the numbers 0, 1 and 2. There's nothing special about them except by convention, and forgetting that can cause hilarious bugs.
I believe I am saying child processes can write to stdout as the main process is shutting down. Also, if the child processes are not shut down properly and are left dangling, and the child processes were set up as 'inherit' to be able to write directly to stdout/stderr then yes.
Fearless concurrency with Rust unless you are worried about lifecycle management, threads/co-operation and general ergonomics. Even modern c++ might be better at this (gasp!) with std::jthread
Are there any languages that provide for or care about lifecycle management across address space boundaries? After fork() you're usually fucked and need explicit controls.
The graceful shutdown stuff is good, but always piping the output of child processes is not necessarily the right thing to do. Some processes need stdin (what if it's a shell?) and some processes will be checking if stdout is a tty. What you should do (and Rust doesn't make this easy) is allocate a new pty for your child processes if your own stdout is a tty. Some programs default to this (eg: ssh), others make it configurable (eg: docker).
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.
>Also, if the terminal is in raw mode then you'll never get ctrl+C.
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.
Don't use PR_SET_PDEATHSIG. That way lies pain.
I’ve definitely seen all of these problems in Rust programs but they certainly aren’t limited to Rust programs. I do think it would be nice if Rust libraries were a bit more misuse-resistant when it came to preserving a coherent terminal.
I also long for a more misuse-resistant terminal but that seems like a bigger problem.
Nothing here is specific to Rust and applies to any terminal app in any language that spawns a child process.
Nothing, that is, except for the examples, the source code, the libraries, and the linked references. But nothing else.
Are you suggesting that the examples, source, libraries, and references for Rust make these mistakes, but other languages don't?
I hate to be the guy, but I could barely see the code snippets. Is contrast an issue for anyone else? Reader mode improves thins slightly but at the cost of code being unhighlighted and wrapping like crazy.
Yes, the contrast of the code examples is not great. Grey on grey, light pastels and orange does not combine into an easy-to-read color palette for me.
LGTM on a MBP + Brave browser.
Are you saying that after the main process has exited, child processes can still run and write to stdout/stderr?
Child processes are created using, generally, 2 syscalls: fork, then exec. When you fork, all file descriptors the main process has open are copied, and are now open in two places. Then, when the child calls exec (to transform itself into the target program), all file descriptors stay open in the new process (unless a specific fd is explicitly configured otherwise, FD_CLOEXEC).
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.
fork() when followed by exec*() is generally inefficient. That's why vfork(), clone(), and clone3() exist. There's no point in duplicating (even CoW) the entire kernel side and libc internal state of a process if it's going to be replaced with exec*() by a new, unrelated process.
Yes, this is easy to test too:
You'll see the message printed out 1 second after the process ends.fd's don't inherently belong to a process, and indeed there are several ways of asking the kernel to pass an fd to another process.
stdin/out/err is just a shorthand (well, longhand) for the numbers 0, 1 and 2. There's nothing special about them except by convention, and forgetting that can cause hilarious bugs.
I believe I am saying child processes can write to stdout as the main process is shutting down. Also, if the child processes are not shut down properly and are left dangling, and the child processes were set up as 'inherit' to be able to write directly to stdout/stderr then yes.
Fearless concurrency with Rust unless you are worried about lifecycle management, threads/co-operation and general ergonomics. Even modern c++ might be better at this (gasp!) with std::jthread
Are there any languages that provide for or care about lifecycle management across address space boundaries? After fork() you're usually fucked and need explicit controls.
I believe Rust's std::thread::scope is an equivalent.
> 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.
Heretic!
Yes, and if you update to a version of LLVM that was released literally a week ago, jthread exists.
This title was close to being a garden path sentence, but ultimately avoided it.
Yes, daemonized children must always be killed; preferably by the parent, but any reaper would also work.
Is that a forking path sentence? If so, whoosh.
Tell more about garden paths in this context, I'm curious!
I had no idea what a garden path sentence was, too, but wiki to the rescue:
https://en.wikipedia.org/wiki/Garden-path_sentence
The old man the boat
Time flies like an arrow,
fruit flies like a banana.