[gambit-list] open-input-file, read and fifos

Marc Feeley feeley at iro.umontreal.ca
Fri Feb 1 10:08:54 EST 2008


On 1-Feb-08, at 6:33 AM, Adrien Pierard wrote:

> First question is "how comes reading a fifo isn't blocking?"
>
> % cd /tmp
> % mkfifo fifo
> % cat > test.scm
> (let ((fifo-port (open-input-file "/tmp/fifo")))
>  (pretty-print (read fifo-port))
>    (close-port fifo-port))
>
> % gsi test.scm
> #!eof
> % echo "hello" > fifo&
> [1] 70455
> % gsi test.scm
> [1]  + done       echo "hello" > fifo
> hello

This is a problem with the named pipe interface on Unix.  When you  
open a named pipe in blocking mode, the open will wait for some  
process to open the writing end of the pipe.  But when you open a  
named pipe in non-blocking mode and no process has yet opened the  
writing end of the pipe, the open will return immediately (which is  
fine) and with *no error condition* (which is not fine... returning  
EAGAIN would have made more sense).

So the only way for Gambit to get the blocking behavior, would be to  
call open without the O_NONBLOCK flag.  But then this would stop the  
thread scheduler because the whole Gambit process would be blocked.

One way around this problem is to get some other process to block on  
the open.  On Unix this can be done with this code:

(let ((fifo-port (open-process (list path: "cat" arguments: (list "/ 
tmp/fifo")))))
   ...)

open-process will start the "cat" subprocess and return a port to read  
the output of "cat".  The "cat" process will block, but this will not  
block Gambit's scheduler.

I guess Gambit's runtime system could take care of this (i.e.  
detecting the file is a named pipe, forking a process, and then  
behaving like cat), but I wonder if it is appropriate because it is  
rather expensive and complex.  All of this to fix a stupid bug in  
Unix's open.

> Second question is "Why do I often have a 'device not configured'  
> error
> with code like the one above?" (Bug not reproduced here, but often  
> happens
> when I try to read or open where nothing is currently being written  
> yet.)

I have never seen this.  So please give more detail on the situation,  
version of Gambit, version of the OS, etc.

> Finally, I would like to know whether we could have a procedure
> WITH-ERROR-TO-FILE to redirect the error port too.

Can you give me a specific situation where you need this?  The  
standard error is seldom used by Gambit's runtime.  So all you will be  
redirecting is your own output which is sent to (current-error-port).

Marc




More information about the Gambit-list mailing list