At this occasion maybe I'd report something I've recently noticed:
On Linux, with beta 21, when you create a named pipe from the shell ($ mkfifo fifo), then, if no writers are connected,
(define f (open-input-file "fifo")) returns immediately, and
(read-line f) returns #!eof immediately. (Only after a writer connects, read-line blocks until data is present.)
"Usually" under unix (without switching on non-blocking I/O) (at least using Perl) the open call blocks if no reader is connected. The read call returns eof after the last writer has closed, and continues to immediately return eof until another writer connects. For this reason, after the first eof I re-open fifo's in my Perl code (to avoid running in a 100% cpu burning loop). This is somewhat weird, too, of course, but I take that is just how it could sensibly work that doesn't differentiate between several writers. (Unix domain sockets don't have these problems of course.)
Now I'm not sure if open-input-file really has to be made to behave the same way in Gambit; in my app it wasn't a problem (not sure anymore why, but I think I moved on to unix domain sockets anyway in the end). In any case I would definitely not recommend a fix that would require a stat(2) call on the file before each open to find out whether it is a fifo (because of the overhead and the race involved). If it can be fixed in another way then fine.
Christian.