> The new GIL does away with this by ditching -Py-Ticker entirely and > instead using a fixed interval (by default 5 milliseconds, but settable) > after which we ask the main thread to release the GIL and let another > thread be scheduled. I've looked at this part of the implementation, and have a few comments. a) why is gil-interval a double? Make it an int, counting in microseconds. b) notice that, on Windows, minimum wait resolution may be as large as 15ms (e.g. on XP, depending on the hardware). Not sure what this means for WaitForMultipleObjects; most likely, if you ask for a 5ms wait, it waits until the next clock tick. It would be bad if, on some systems, a wait of 5ms would mean that it immediately returns. c) is the gil-drop-request handling thread-safe? If your answer is "yes", you should add a comment as to what the assumptions are of this code (ISTM that multiple threads may simultaneously attempt to set the drop request, overlapping with the holding thread actually dropping the GIL). There is also the question whether it is thread-safe to write into a "volatile int"; I keep forgetting the answer. Regards, Martin