Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: 1) volatile is not required when access is guarded by locks. 2) pendingcalls_to_do is initialized to 1, so the very first thing that the interpreter does (after executing one bytecode, I init _PyTicker to 0 now) is to initialize this lock. Creating a lock really must be done by one well known startup thread only. There is a lot of functions in the python API that don't work until after python initialization (without that being explicitly documented), Py_AddPendingCall() is one of them. Btw, there is no generic "init" function for the ceval.c module. And PyEval_InitThreads isn't really suitable since we must have the lock, even if we haven't initialized the threads, to guard us against reentrancy during signal delivery. For extra safety, I have added a NULL test in Py_AddPendingCall(). 3)Py_AddPendingCall() can be called with our without the GIL. 4)I've added a check in Py_MakePendingCalls(). In PyEval_ReInitThreads there is no way to do anything sensible in the case of error. 5)Yes it is reentrant. The pending_lock is only held for a short while while we pop a callback off the queue. However, because even during that short while a signal can be delivered which causes Py_AddPendingCall() to be called, the latter function fails if it doesn't acquire the lock in a reasonable amount of time. This would cause a signal to be lost, and not a deadlock. This hasn't changed from the old implementation.
I have also added a flag to make sure that we don't execute pending calls recursively, (async notifications is so much better) and explained it better in the docs. Added file: http://bugs.python.org/file12624/pendingalls.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
