Skip to content

EINTR handling in fcntl #70903

Closed as duplicate
Closed as duplicate
EINTR handling in fcntl#70903
Labels
extension-modulesC modules in the Modules dirtopic-IOtype-bugAn unexpected behavior, bug, or error

Description

@JackZhou
JackZhou
mannequin
opened on Apr 8, 2016
BPO 26716
Nosy @Yhg1s, @vstinner, @serhiy-storchaka
Files
  • fcntl_eintr.patch
  • fcntl_eintr-2.patch
  • fcntl_eintr-3.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = None
created_at = <Date 2016-04-08.19:50:33.306>
labels = ['extension-modules', 'type-bug', 'expert-IO']
title = 'EINTR handling in fcntl'
updated_at = <Date 2016-04-17.15:16:04.118>
user = 'https://bugs.python.org/JackZhou'

    bugs.python.org fields:

    activity = <Date 2016-04-17.15:16:04.118>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules', 'IO']
creation = <Date 2016-04-08.19:50:33.306>
creator = 'Jack Zhou'
dependencies = []
files = ['42409', '42474', '42498']
hgrepos = []
issue_num = 26716
keywords = ['patch']
message_count = 13.0
messages = ['263042', '263075', '263076', '263078', '263086', '263134', '263258', '263271', '263277', '263391', '263507', '263512', '263613']
nosy_count = 6.0
nosy_names = ['twouters', 'vstinner', 'neologix', 'python-dev', 'serhiy.storchaka', 'Jack Zhou']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue26716'
versions = ['Python 3.5', 'Python 3.6']

    Activity

    1. JackZhou commented on Apr 8, 2016

      @JackZhou
      JackZhoumannequin
      on Apr 8, 2016
      MannequinAuthor

      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()))
    2. JackZhou
      added
      topic-IO
      type-bugAn unexpected behavior, bug, or error
      on Apr 8, 2016
    3. SilentGhost
      added
      extension-modulesC modules in the Modules dir
      on Apr 8, 2016

    4. python-dev commented on Apr 9, 2016

      @python-dev
      python-devmannequin
      on Apr 9, 2016
      Mannequin

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

    5. vstinner commented on Apr 9, 2016

      @vstinner
      vstinner
      on Apr 9, 2016
      Member

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

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

    6. serhiy-storchaka commented on Apr 9, 2016

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 9, 2016
      Member

      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.

    7. vstinner commented on Apr 9, 2016

      @vstinner
      vstinner
      on Apr 9, 2016
      Member

      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.

    8. serhiy-storchaka commented on Apr 10, 2016

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 10, 2016
      Member

      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

    9. vstinner commented on Apr 12, 2016

      @vstinner
      vstinner
      on Apr 12, 2016
      Member

      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?

    10. serhiy-storchaka commented on Apr 12, 2016

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 12, 2016
      Member

      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?

    11. vstinner commented on Apr 12, 2016

      @vstinner
      vstinner
      on Apr 12, 2016
      Member

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

    12. python-dev commented on Apr 14, 2016

      @python-dev
      python-devmannequin
      on Apr 14, 2016 · Hidden as off-topic

    13. vstinner commented on Apr 15, 2016

      @vstinner
      vstinner
      on Apr 15, 2016
      Member

      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

    14. serhiy-storchaka commented on Apr 15, 2016

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 15, 2016
      Member

      Left nitpicks about tests.

    15. vstinner commented on Apr 17, 2016

      @vstinner
      vstinner
      on Apr 17, 2016
      Member

      I updated the test, does it look better now?

    16. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    17. serhiy-storchaka commented on Apr 21, 2025

      @serhiy-storchaka
      serhiy-storchaka
      on Apr 21, 2025
      Member

      It was implemented in bpo-35189 (#79370).

    18. serhiy-storchaka
      closed this as duplicateon Apr 21, 2025
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      extension-modulesC modules in the Modules dirtopic-IOtype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions