Fixing Ctrl+C in Rust terminal apps: Child process management

That's good to know; ysh[1] will treat pipelines with a SIGPIPE indicative exit code as successful to allow e.g.

  foo |head -n2

1: https://oils.pub/release/latest/doc/ysh-tour.html

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

So none of this should be fixed in Rust just because others have the same problems?

Nothing, that is, except for the examples, the source code, the libraries, and the linked references. But nothing else.

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.

Yes, this is easy to test too:

    #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;
    }

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.

When you use ctrl+c, you are not killing the program, you are sending it a SIGTERM signal which essentially means « could you please stop yourself ? » so the program have a chance to clean things before exiting.

kill -9 is sending a SIGKILL signal which, well, kills the program immediately.

The highlighting is clearly designed for a dark background but has been given a light background in light mode. Change the bg-neutral-100 to bg-neutral-900 and it’s fine—still not magnificent, but fine.

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

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.

Yes, daemonized children must always be killed; preferably by the parent, but any reaper would also work.

I have never undestood why garden path sentences are interesting. They can always be rewritten to make more obvious sense. Its like saying theres a way to take any sentence and remove some words to make its intended meaning confusing. I dont personally find this interesting, just frustrating that the author didnt take more time to use punctuation or more words to convey explicit meaning.

Tell more about garden paths in this context, I'm curious!

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.

Ok, but I am literally getting filtered by installing C++ libraries. I haven't accomplished anything in the last 5 days other than determine that the previous libraries are not usable.

Heretic!

Yes, and if you update to a version of LLVM that was released literally a week ago, jthread exists.