[Python-Dev] Killing threads

[Tim Peters]

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

And better than most <heh>.