[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