Are all descriptions of the "caveats", listed near the end of _thread module's docs, up to date?

[eryksun]

@zuo

Are there any platforms for which _threads is available and signal is not?

The signal module should always be available on the currently supported platforms. Note that on Windows, the C runtime library just emulates a few signals, since Windows does not implement POSIX signals^[1].

@zuo

• When the main thread exits, it does not do any of its usual cleanup (except that try … finally clauses are honored), and the standard I/O files are not flushed.

That’s not right. If the main thread exits normally back to Py_RunMain() or if it raises SystemExit, then Py_FinalizeEx() gets called, which, among other things, shuts down the threading module and calls Python atexit functions. If the process exits via C exit() or _exit(), then Py_FinalizeEx() isn’t called, so threading isn’t shut down and Python atexit functions aren’t called.

---

1. SIGBREAK and SIGINT are based on the corresponding console control events. SIGSEGV, SIGILL, and SIGFPE are based on the corresponding OS exceptions. SIGABRT and SIGTERM are emulated just for use with C raise() and abort(). There isn’t support in Python for handling SIGSEGV, SIGILL, SIGFPE, and SIGABRT due to the design of the C signal handler, which just sets a flag and returns. Also, handling SIGINT and SIGBREAK is broken when reading from the console/terminal since EOFError is raised instead of restarting the read. ↩︎