[Python-Dev] Killing threads (original) (raw)

Tim Peters tim.one@home.com
Tue, 29 May 2001 00:03:38 -0400

[Jeff Epler, on http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=426735 ]

My reasoning: The documentation for exit() says it is "used to exit the child process after a fork()", and my model for thinking about threads is that they're "child processes, but ...". Thus, invoking os.exit() in a thread made sense to me, meaning "ask the OS to destroy this thread now, but leave my file descriptors, etc., alone for the other threads."

You need a Linux expert to address this. Threads and processes are different beasts under most flavors of Unix, but Linux confuses them; I've no idea how _exit() is supposed to work there, and that's why I asked (in the bug report) what the Linux docs say about that (_exit() is supplied by your local C library; Python just wraps it).

If what you really wanted was just to abort the thread, use thread.exit() (aee the thread docs). os._exit() is a dangerous thing even in the best of conditions; unsure why the Python docs suggest using it.

Your suggestion in the tracker of writing the equivalent C program is a good one, though my suspicion (which I did not voice in the SF report) was that perhaps the thread which called exit() held the GIL, in which case it was in some sense Python's fault that execution didn't continue.

Ah, makes sense! Yes, I bet that's what's happening. If so, there's nothing Python can do about it: I'm afraid you did it to yourself. _exit() specifically asks that no cleanup processing be done, and when Python calls it Python never regains control. If you had done an actual fork, fine, the process doing the _exit() would never come back to Python, but the GIL in that process has nothing to do with the GIL in the parent process. But threads share the same GIL, and if you _exit() from a thread holding the GIL then no other thread can ever run again.

Looks like it's also platform-dependent: on Windows, _exit() kills the process and every thread ever spawned by that process. Since C doesn't say anything about threads, that can't be called right or wrong. Looks like on Linux _exit() only kills the thread that calls it.

... Of course, if os.exit() has no intended use in a threaded program,

Right, it wasn't -- unless your program panics and wants to get out ASAP no matter what the consequences.

then this behavior is as good as any.

And better than most .