7 ms·
Well, that's the source of the bug in Python as well so it's not exactly a unique choice or default. It's tricky to manage this in a cross-platform way.
by mprovost 3y ago
Well, that's the source of the bug in Python as well so it's not exactly a unique choice or default. It's tricky to manage this in a cross-platform way.
- gumby 3y agoI consider it malpractice
- kelnos 3y agoPython is a high-level language, though, and python code is run through an interpreter, so it's not a surprise that it might handle signals (and other things) differently than your average program. (Not restoring signals handlers to their default on fork()/exec() is definitely a bug, though.) Rust is intended to be a systems programming language, and a replacement for C/C++. It should not be mucking about with signal handler defaults before main() runs. The one thing that Rust does right, though, is it resets SIGPIPE to SIG_DFL when spawning processes[0]. Of course, I assume it only does that if you use std::process::Command, not if you use libc::fork()/libc::exec(), or get there some other way. [0] https://doc.rust-lang.org/beta/unstable-book/language-features/unix-sigpipe.html#note-on-child-processes https://doc.rust-lang.org/beta/unstable-book/language-featur...
- lelanthran 3y ago> Well, that's the source of the bug in Python as well so it's not exactly a unique choice or default. It's tricky to manage this in a cross-platform way. Well, Python wasn't intended to write the sort of programs that C and Rust gets used for. In Python, such a choice is not necessarily a design failure. In systems languages it is.