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