[Python-Dev] pthread sem PyThread_acquire_lock

[Phillip Sitbon]

I'll do my best to try and explain/contribute, but please feel free to
correct anything I get wrong.

I believe the "swallowing" he's referring to is the ignoring of errno
EINTR. I don't think that's the correct place to handle signals to
begin with- why not just use the signal module to deal with such a
scenario?

http://docs.python.org/dev/library/signal.html#module-signal

AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
There are many functions that don't return this value anymore, making
them reentrant. I remember a number of years ago when it wasn't part
of any standard to return EINTR or not, and so the only way to provide
consistent behavior was to ignore it and loop. I'm not sure if that is
still the case.

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.

Cheers,

Phillip


On Sat, Jun 27, 2009 at 3:58 PM, Florian Mayer <flormayer at aim.com> wrote:
>
> Martin v. Löwis wrote:
>>
>> Can you please explain what you mean by "swallowing"?
>
> The signals don't get through when acquiring the lock.
>>
>> What is the sequence of actions triggering the case you are talking
>> about, what happens, and what do you expect to happen instead?
>
> Easiest way is to create a Queue.Queue and call .get() on it and try to Ctrl-C it.
>>
>> Also, how would you fix this (in principle, not what the specific
>> patch would look like)?
>
> Remove the loop that explicitly does this in a new function and use that
> one in threadmodule.c for lock.acquire.
>>
>> Regards,
>> Martin
>
> Best regards,
> Florian
>
> PS: Excuse me, I messed up things once again.
>
> _______________________________________________
> 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/phillip.sitbon%2Bpython-dev%40gmail.com