Date: Thu, 17 Sep 2015 15:34:38 +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-XhvQIyURfT@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=203162 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161136|0 |1 is obsolete| | --- Comment #7 from Konstantin Belousov <kib@FreeBSD.org> --- Created attachment 161150 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161150&action=edit Ignore signal after a wakeup, if there was a complimentary open, even transient The new version of the patch is even more aggressive with preferring a normal return when there is both signal delivered and parallel open. Now, I run several thousand iterations of your test without hang, while before it would reliably hang on first or second dozens. Some clarification about signals. Patch does not cause the signal to be lost. Before the patch, you get EINTR error when signal was generated _and_ parallel complimentary type of open happen. Now, the syscall returns with success and file descriptor, but before the usermode continues, a signal frame is pushed on stack and signal handler run. In other words, things are changed so that it _looks_ like the signal was delivered slightly after the wakeup from open. -- 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-XhvQIyURfT>