Yes it looks like you might be right about those hanging buildbots. The occasional successes (e.g. <http://buildbot.python.org/all/builders/s390x%20Debian%202.7/builds/205/steps/test/logs/stdio>) seem to happen when test_thread runs before any of the TK, TCL, and Idle tests.

The reason why this does not affect Python 3 is probably because the test only calls sys.exit() in Python 2; this code was added in r78527. In Python 3, the code was merged in revision 58c35495a934, but the code was apparently changed to call os._exit() at the same time. So one potential fix or workaround could be to change to os._exit() as in child-exit.patch.

It seems Tcl_FindExecutable() creates a thread, and this thread survives fork(). (Perhaps it is re-created?) Python exiting does not cause this thread to be stopped. Playing with “strace” it seems the threads that return from fork() in the parent and child both finish with _exit(0). However the “main” thread in the parent finishes with exit_group(0), which is documented as terminating all threads. Calling os._exit() also seems to call exit_group(), which explains why that fixes the problem in the child.

I can produce the problem in all versions of Python without using _tkinter, using the following code instead:

import _thread, os, time

def thread1():
    pid = os.fork()
    if not pid:                                            
        # In the child, the original main thread no longer exists. Start a
        # new thread that will stall for 60 s.
        _thread.start_new_thread(time.sleep, (60,))

_thread.start_new_thread(thread1, ())
time.sleep(2)  # Give fork() a chance to run

I’m not really sure, but maybe Python could improve its handling of this case, when fork() is called on a non-“main” thread and another thread is also running in the child process.