sporadic crashes in multi-thread programs when several long deallocator
chains ran concurrently and involved subclasses of built-in container
types.
Because of this change, a couple extension modules compiled for 2.7.4
(those which use the trashcan mechanism, despite it being undocumented)
will not be loadable by 2.7.3 and earlier. However, extension modules
compiled for 2.7.3 and earlier will be loadable by 2.7.4.
TLS implementations, and fails with the ad-hoc TLS implementation when a thread
doesn't have an auto thread state (e.g. a thread created outside of Python
calling into a subinterpreter).
key list data structure in the thread startup path.
This change is a companion to r60148 which already successfully dealt with a
similar issue on thread shutdown.
In particular this loop has been observed happening from this call path:
#0 in find_key ()
#1 in PyThread_set_key_value ()
#2 in _PyGILState_NoteThreadState ()
#3 in PyThreadState_New ()
#4 in t_bootstrap ()
#5 in pthread_start_thread ()
I don't know how this happens but it does, *very* rarely. On more than
one hardware platform. I have not been able to reproduce it manually.
(A flaky mutex implementation on the system in question is one hypothesis).
As with r60148, the spinning we managed to observe in the wild was due to a
single list element pointing back upon itself.
PyThreadState_Delete() to avoid an infinite loop when the tstate list
is messed up and has somehow becomes circular and does not contain the
current thread.
I don't know how this happens but it does, *very* rarely. On more than
one hardware platform. I have not been able to reproduce it manually.
Attaching to a process where its happening: it has always been in an
infinite loop over a single element tstate list that is not the tstate
we're looking to delete. It has been in t_bootstrap()'s call to
PyThreadState_DeleteCurrent() as a pthread is exiting.
Building with HP's cc on HP-UX turned up a couple of problems.
_PyGILState_NoteThreadState was declared as static inconsistently.
Make it static as it's not necessary outside of this module.
Some tests failed because errno was reset to 0. (I think the tests
that failed were at least: test_fcntl and test_mailbox).
Ensure that errno doesn't change after a call to Py_END_ALLOW_THREADS.
This only affected debug builds.
PyThreadState_SetAsyncExc(): internal correctness changes wrt
refcount safety and deadlock avoidance. Also added a basic test
case (relying on ctypes) and repaired the docs.
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
PyThreadState_Delete(): if the auto-GIL-state machinery knows about
the thread state, forget it (since the thread state is being deleted,
continuing to remember it can't help, but can hurt if another thread
happens to get created with the same thread id).
I'll backport to 2.4 next.
