Date: Thu, 17 Sep 2015 09:33:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 203162] when close(fd) on a fifo fails with EINTR, the file descriptor is not really closed Message-ID: <bug-203162-8-4SmTQy8KnU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-203162-8@https.bugs.freebsd.org/bugzilla/> References: <bug-203162-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203162 --- Comment #5 from Victor Stinner <victor.stinner@gmail.com> --- "The patch would prefer to return success over the EINTR when signal is delivered while other end of fifo becomes ready simultaneously." Do you mean that the signal will be delivered later to the application? Ignoring completly a signal doesn't sound like a good idea :-) "Note that the patch still does not fix the fundamental underground issue of the troubles, which is in the test structure itself." I'm not sure that I understand: do you mean that the test has a race condit= ion? FYI the Python test suite is executed on a wide range of architectures and platforms: http://buildbot.python.org/all/waterfall?category=3D3.x.stable&category=3D3= .x.unstable The test_eintr test is executed and pass on Linux, Mac OS X, Solaris (and OpenIndiana), OpenBSD, etc. For FreeBSD, test_eintr hangs 50% of the time (= raw estimation). For OpenBSD, I'm not sure, the buildbot is currently disabled. For Mac OS X, I'm surprised, I thaught that Mac OS X stole a large part of FreeBSD code := -) Well... I had a lot of trouble to write a reliable C program to reproduce t= he issue, so the test may hangs on any platform, but I didn't notice hang (I d= on't check _each_ build of each platforms, it would take too much time). But at least, I can say that the bug fails frequently on FreeBSD, whereas I never saw it failing on Linux. "If child reader manages to close fifo before the parent writer sleeping in open has a chance to run, parent would deadlock, since nothing else would o= pen the fifo for read." On Linux, the open(O_RDONLY) in the child blocks until the open(O_WRONLY) succeed. The Linux kernel looks to ensure that both open succeed "at the ti= me same". Short test in Python. Parent: $ python3 Python 3.4.2 (default, Jul 9 2015, 17:24:30)=20 [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux >>> import os >>> os.mkfifo("fifo") >>> f=3Dopen("fifo", "wb") ^Z [1]+ Stopp=C3=A9 python3 -q Child: haypo@smithers$ python3=20 Python 3.4.2 (default, Jul 9 2015, 17:24:30)=20 [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux >>> f=3Dopen("fifo", "rb") I used CTRL+z to stop the parent process: the child process hangs until I restart the parent process (using "fg"). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-203162-8-4SmTQy8KnU>