[Python-Dev] pthread sem PyThread_acquire_lock

[Guido van Rossum]

On Thu, Jul 2, 2009 at 4:04 PM, Jean-Paul Calderone<exarkun at divmod.com> wrote:
> On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" <greg at krypto.org>
>> If you want signals to actually be handled in a timely manner, its
>> best to leave the main thread of the program alone as a signal
>> handling thread that just spends its time in a loop of time.sleep(123)
>> calls rather than blocking on any sort of lock.  Spawn other threads
>> to do the actual work in your program.  Signals are delivered
>> indirectly in the existing CPython implementation by setting an
>> internal flag that the main interpreter thread polls on occasion so
>> blocking calls that do not interrupt and return early being called
>> from the main thread will effectively block signals.
>
> Yes, this is all true now.  The question is why the implementation
> works that way, and whether it is desirable to keep it working that
> way.
>
> Considering *some* of the lock implementations make themselves not
> interruptable by threads while others don't bother, it seems like
> *some* change to the status quo is desirable.

I'm probably to blame for this, but IIRC when we did it, lock
acquisitions were not interruptible by signals. However, that was
before posix threads were even standardized. Nowadays I believe we use
pthreads everywhere except on Windows. But I know nearly nothing about
pthreads. If pthreads mutex acquisition is (or can easily be made)
interruptible by signals I'd be all for adding signal handling to
them, assuming it doesn't slow things down much. Also, if there are
ways to do the "try to acquire a lock or wait until a given timeout"
natively and while handling signals, that would be a great
improvement.

I'll probably regret saying this within an hour though,

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)