31–40 of 62 posts
Earlier quoted context omitted.
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?
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 co…
>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 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.
(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.)
It seems wrong that the app would be responsible for cleanup... Shouldn't this be solved in the shell / terminal ? What if kill -9?
kill -9 is sending a SIGKILL signal which, well, kills the program immediately.
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 descripto…
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.
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.
Nothing here is specific to Rust and applies to any terminal app in any language that spawns a child process.