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.