[Python-Dev] pthread sem PyThread_acquire_lock

[Jean-Paul Calderone]

On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" <greg at krypto.org> wrote:
>On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis"<martin at v.loewis.de> wrote:
>>> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
>>
>> This is my understanding as well - so I don't think Python actually
>> "swallows" the signal.
>>
>>> A great example is reading from a socket. Whether or not it can be
>>> interrupted depends on the platform, so catching Ctrl+C often requires
>>> a timeout loop.
>>>
>>> Also, remember that signals are asynchronous in the sense that they
>>> are handled outside the normal execution flow of a program. Checking
>>> for EINTR probably isn't the best way to determine if a signal has
>>> been sent to the program.
>>
>> I think it would be reasonable to support "asynchronous" exceptions,
>> and Python supports SIGINT fairly well most of the time.
>>
>> It might be possible to support keyboard interrupts throughout
>> the system, but changing Python to do so could also cause
>> incompatibilities. So any change must be done with greatest care,
>> but simultaneously, should also try to arrange to cover all cases.
>>
>> Regards,
>> Martin
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.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.

Jean-Paul