My client is trying to build a version of Python on Windows with Tkinter and pymalloc enabled, and threads disabled (in part because pymalloc is not thread-safe). There appears to be a bug in _tkinter.c:EventHook. It has this code:
#if defined(WITH_THREAD) || defined(MS_WINDOWS) Py_BEGIN_ALLOW_THREADS PyThread_acquire_lock(tcl_lock, 1); tcl_tstate = event_tstate;
result = Tcl_DoOneEvent(TCL_DONT_WAIT);
tcl_tstate = NULL; PyThread_release_lock(tcl_lock); if (result == 0) Sleep(20); Py_END_ALLOW_THREADS #else result = Tcl_DoOneEvent(0); #endif
It seems on the surface that the "|| defined(MS_WINDOWS)" bit should be deleted. This code dates from 1998 and comes with this log text:
revision 1.72 date: 1998/06/13 13:56:28; author: guido; state: Exp; lines: +26 -6 Fixed the EventHook() code so that it also works on Windows, sort of. (The "sort of" is because it uses kbhit() to detect that the user starts typing, and then no events are processed until they hit return.)
Also fixed a nasty locking bug: EventHook() is called without the Tcl lock set, so it can't use the ENTER_PYTHON and LEAVE_PYTHON macros, which manipulate both the Python and the Tcl lock. I now only acquire and release the Python lock.
(Haven't tested this on Unix yet...)
This suggests that Guido was (rightly) worried about the case of threading on Windows. What about a non-threaded interpreter on Windows?
My client is trying to build a version of Python on Windows with Tkinter and pymalloc enabled, and threads disabled (in part because pymalloc is not thread-safe).
Using pymalloc with threads should be safe as long as you don't have extensions that call pymalloc without the big lock held.