Date: Sun, 8 Oct 1995 15:32:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: FreeBSD-Hackers@FreeBSD.ORG, chuckr@eng.umd.edu Subject: Re: FIFO stuff Message-ID: <199510082232.PAA07347@phaeton.artisoft.com> In-Reply-To: <199510072139.HAA03662@godzilla.zeta.org.au> from "Bruce Evans" at Oct 8, 95 07:39:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >I looked at the finger source, and the .plan file is checked to see if > >it's there, and if it's non-zero length. OK, I got it to check if it was > >a fifo, and if it was, not do the non-zero length check, but reading the > >fifo seems to be a problem. Finger wants to do a character by character > >read, and check if any of the returns are EOF. Since it may do a read > >before masterplan has genned a new response file, it gets this EOF before > >the masterplan program has had time to respond. > > Just reading it should work. The open should block until something > writes the the fifo, and read should not return 0 until the fifo is not > open for writing by any process. .plan must remain a fifo throughout. > I don't think this can be made to work properly if masterplan replaces > .plan with a fifo on the fly. I believe the problem is that a non-blocking open on a FIFO fails to cause the use of non-blocking reads. I put one patch up for this, but it was insufficient (I noted this in the patch at the time). It would require me setting up a testbed to crrect this problem, and my current machine resources are all committed (I don't have room for all of Masterplan). I also do not have time to tract the FIFOFS problems further, other than to acknowledge that yes, according to the code, that is correct behaviour. Clearly, it's not what Masterplan expects, and it may in fact require a reimplementation of the FIFO code to fix. I plan on waiting on doing *anything* like this until the struct fileops bogosity is removed from /sys/sys/file.h. This will take some cleanup on several file systems, notable specfs. Hopefully specfs will be dying in any case, to be replaced in all instances by symlinks to a permanently mounted devfs. That would make the necessary POSIX domain socket code repairs (probably a rewrite) on which the FIFO code is implemented a lot simpler. Unless someone wants to take this on now, it's probably something that will require a kludge patch to make work. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510082232.PAA07347>