Date: Wed, 16 Sep 2015 23:36:28 +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-WBSf25c5oI@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 --- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Victor Stinner from comment #1) I see the 'hang', where the parent is sleeping on open(O_WRONLY), and there is no child. The situation is not too mysterious, see the explanation below. Test sets up two processes, parent does open(fifo, O_WRONLY), child does open(fifo, O_RDONLY). Either process can proceed further if other process enters open(), or a signal is delivered interrupting the sleep waiting for the residual open. Assume that the parent sleeps in open waiting for child/reader, child enters open and since there is writer waiting, the open in child succeeded. Child wakes up the parent to notify that open(O_WRONLY) can succeed as well (there is reader after all). And, the crusial point, assume that the parent gets signal notification before it gets wakeup notice. In this setup, open() in parent returns with EINTR. On the other hand, child successfully opened fifo for read, and after some more work, it exits. But the parent retries the open(O_WRONLY). There is no child to open fifo, so open() cannot succeed, it only gets interrupted by signal periodically. And, parent would not start another child until this open succeed. Hopefully this can be followed. FWIW, do not use truss, use kdump -i. -- 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-WBSf25c5oI>