[Python-Dev] pthread sem PyThread_acquire_lock

[Gregory P. Smith]

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.