According to PEP 475, standard library modules should handle EINTR, but this appears to not be the case for the fcntl module.

Test script:


import fcntl
import signal
import os


def handle_alarm(signum, frame):
    print("Received alarm in process {}!".format(os.getpid()))


child = os.fork()
if child:
    signal.signal(signal.SIGALRM, handle_alarm)
    signal.alarm(1)
    with open("foo", "w") as f:
        print("Locking in process {}...".format(os.getpid()))
        fcntl.flock(f, fcntl.LOCK_EX)
        print("Locked in process {}.".format(os.getpid()))
        os.waitpid(child, 0)
else:
    signal.signal(signal.SIGALRM, handle_alarm)
    signal.alarm(1)
    with open("foo", "w") as f:
        print("Locking in process {}...".format(os.getpid()))
        fcntl.flock(f, fcntl.LOCK_EX)
        print("Locked in process {}.".format(os.getpid()))

New changeset 60ac28b612af by Victor Stinner in branch '3.5':
Update fcntl doc: replace IOError with OSError
https://hg.python.org/cpython/rev/60ac28b612af

Oh, we forgot the fcntl module in the PEP 475.

Here is a fix for Python 3.5 (and 3.6).

It looks to me that interrupting fcntl can be used for implementing blocking lock with a timeout. If automatically retry fcntl() on EINTR, this will break such code.

Serhiy Storchaka added the comment:
> It looks to me that interrupting fcntl can be used for implementing
blocking lock with a timeout. If automatically retry fcntl() on EINTR, this
will break such code.

If the signal handler doesn't raise an exception, the code is not reliable.
It's a common complain about the PEP 475.

If the signal handler raises an exception, it's work on Python 2.7 and on
Python 3.5 with my patch.

The signal handler doesn't raise an exception in the example on StackOverflow. [1]

I think it would be nice to publish somewhere (on ActoveState receipts, on StackOverflow) well-searchable correct example.

[1] http://stackoverflow.com/questions/5255220/fcntl-flock-how-to-implement-a-timeout

> I think it would be nice to publish somewhere (on ActoveState receipts, on StackOverflow) well-searchable correct example.

Yeah, it's always possible to enhance the doc. I'm not an user of ActiveState or StackOverflow websites. Don't hesitate to submit a comment to explain the PEP 475 ;-)

Is it ok to fix Python 3.5? Or is it safer to only fix the issue in Python 3.6?

I just don't know whether the patch will break existing code that relies on current behavior. If EINTR handling in other functions was not backported to older versions, I think this is good argument against fixing this issue in 3.5.

Could you write tests with signal handlers raising and not raising an exception?

Ok, I will update the patch to include an unit test and only apply it
to Python 3.5.

New changeset 9ffe055f2b0e by Serhiy Storchaka in branch '3.5':
Issue #26716: Regenerate Argument Clinic code.
https://hg.python.org/cpython/rev/9ffe055f2b0e

New changeset 19dec08e54a8 by Serhiy Storchaka in branch 'default':
Issues #26716, #26057: Regenerate Argument Clinic code.
https://hg.python.org/cpython/rev/19dec08e54a8

Patch version 2:

* add a comment to explain the C loop retrying on EINTR error
* add an unit test: I checked that the test fails with InterruptedError without the fix
* document the change in fcntl documentation

Left nitpicks about tests.

I updated the test, does it look better now?