FreeBSD + FIFO pipes
A workaround for all systems is to open the FIFO for writing yourself, before (or at the same time as) opening it for reading. What does it mean "open the FIFO for writing yourself"? I've tried putting in
Yes I know it's a FAQ, but despite the information in the GHC FAQ I can't get my program to work. I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) <- Posix.createPipe (readOut,writeOut) <- Posix.createPipe It then forks off a process which first dup2's readIn onto its stdin and writeOut onto its stdout, and then runs the Tcl/Tk shell wish (which does graphics). The idea is that sending commands along writeIn will cause them to be executed by wish, and wish's output can be read from readOut. We do the reading/writing of readOut/writeIn using the Posix fdRead/fdWrite primitives. In addition, before every call to fdRead we do a Posix.threadWaitRead on it, to make sure there is actually input there. All this works fine on Linux and Solaris by the way. (On Windows we use a completely different mechanism.) The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly. The GHC FAQ says: the following lines immediately after creating the pipes
byteCountOut <- fdWrite writeOut "#" (strIn,byteCountIn) <- fdRead readOut 1 case (byteCountOut,byteCountIn,strIn) of (1,1,"#") -> done x -> error ("ChildProcess.999 error"++show x)
byteCountOut <- fdWrite writeIn "#" (strIn,byteCountIn) <- fdRead readIn 1 case (byteCountOut,byteCountIn,strIn) of (1,1,"#") -> done x -> error ("ChildProcess.9998 error"++show x)
which just write a single character down each pipe; unfortunately this doesn't seem to help. Any other suggestions? By the way this is all GHC5.04.1, which seems to be the last FreeBSD version available, at least with pkg_add. Thanks. George Russell
In local.glasgow-haskell-users, you wrote:
I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) <- Posix.createPipe (readOut,writeOut) <- Posix.createPipe The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly.
Can you cut this down to a simple program, maybe executing /bin/echo instead of 'wish'? Notice that the FAQ doesn't apply here as the FAQ talks about FIFO createt by mkfifo (which exist in the file system), while you talk about pipes. I'll try to think of something, but I'd be glad if you already had a usable program to reproduce this error. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine
Volker Stolz wrote:> In local.glasgow-haskell-users, you wrote:
I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) <- Posix.createPipe (readOut,writeOut) <- Posix.createPipe The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly.
Can you cut this down to a simple program, maybe executing /bin/echo instead of 'wish'? Notice that the FAQ doesn't apply here as the FAQ talks about FIFO createt by mkfifo (which exist in the file system), while you talk about pipes.
I'll try to think of something, but I'd be glad if you already had a usable program to reproduce this error.
I think this one is going to remain unsolved. I have fixed the problem, by reimplementing the relevant code in a different way (actually resurrecting an old implementation, with a vital fix) and now it works. However the cause of the problem I reported is a mystery to me, and producing a simple test case does not look very easy. Thanks for your help, George
participants (2)
-
George Russell -
Volker Stolz