[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Matthew Woodcraft]

Antoine Pitrou  <solipsis at pitrou.net> wrote:
>Matthew Woodcraft <matthew at woodcraft.me.uk> wrote:
>> (The program handles SIGTERM so that it can do a bit of cleanup before
>> exiting, and it uses the signal-handler-sets-a-flag technique. The call
>> that might be interrupted is sleep(), so the program doesn't strictly
>> _rely_ on the existing behaviour; it would just become very slow to
>> exit.)

> So, if it's just for process exit, just let the signal handler raise an
> exception and catch the exception at the top-level.

I wouldn't recommend that anyone take this advice. The signal might come
at some time other than the sleep(), and introducing an exception which
can mysteriously appear at abitrary points is not a way to make life
easier.

Nonetheless I'm sure my program would be easy enough to fix to use
set_wakeup_fd() or signalfd() if necessary.

I'm not saying we shouldn't make this backwards-incompatible change
because it will be hard to update existing programs to cope; I'm saying
we shouldn't pretend it doesn't count as a backwards-incompatible
change.


In any case I think PEP 475 should be explaining what is going to happen
to signal.siginterrupt(). Will setting flag=True be supported? If so,
will doing so change the behaviour of those parts of the stdlib which
have already been modified to retry after EINTR?

(I think it would be helpful if we could tell people "if you want the
old EINTR behaviour, just do this simple thing". And I suppose
siginterrupt flag=True is a candidate for that.)

-M-