Author rbcollins
Recipients jcea, pitrou, rbcollins
Date 2012-01-03.00:52:42
SpamBayes Score 1.03848e-09
Marked as misclassified No
Message-id <1325551963.58.0.256309919671.issue13697@psf.upfronthosting.co.za>
In-reply-to
Content
I'm not sure it is sensibly implementable in pure python: the semantics of signal handling (AIUI) are that the vm is interrupted, sets a flag to say 'when the GIL is released or the next bytecode interpretation happens, please process signal X' [the former for C extensions, the latter for regular code], and then the OS level signal handler returns. The current C or bytecode execution completes and then we dispatch to the python signal handler.

Now, what we would want here is that attempts to acquire/release the RLock in a signal handler would behave as though the RLock.acquire/release methods were atomic. The general way to enforce such atomicity is via a lock or mutex. Now, because the call stack looks like this:
<signal>thread.acquire()
<non-signal-code>thread.acquire()

The other acquire, if it already holds this supposed mutex, would block the python signal handler acquire call from obtaining it; The inner acquire would have to error *whether or not a timeout was passed*, because the non-signal-code won't progress and complete until the python signal handler code returns. One could, in principle, use stack inspection to determine how far through a nested acquire/release the outer code is, but that seems, uhm, pathological to me :).

The crux of the problem is detecting whether the non-reentrant thread.lock is held because (a) another thread holds it or (b) this thread holds it. If we can inspect its internals, we could determine that this thread holds it - and thus we must be reentered into the acquire/release methods. With that tricky thing established, we could look at the remaining logic to make sure that each line is either atomic or conditional on reentrancy.

Simpler I think to require CRLocks always, and provide a portable C implementation which will always complete before returning to execution in the calling thread, avoiding this issue entirely.
History
Date User Action Args
2012-01-03 00:52:43rbcollinssetrecipients: + rbcollins, jcea, pitrou
2012-01-03 00:52:43rbcollinssetmessageid: <1325551963.58.0.256309919671.issue13697@psf.upfronthosting.co.za>
2012-01-03 00:52:43rbcollinslinkissue13697 messages
2012-01-03 00:52:42rbcollinscreate