FreeBSD + FIFO pipes
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: 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 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: effect of order of function arguments
[moved over to glasgow-haskell-users] On Wed, 19 Feb 2003, Simon Peyton-Jones wrote: | GHC used to have an optimisation for static argument like this. It would | turn both of the above programs into a similar form using a local | recursive function: | | interp y xs = interpaux xs | where interpaux [] = [] | interpaux (x:[]) = x:[] | interpaux (x:xs) = x:y:interpaux xs | | GHC doesn't do this anymore. The reason for this is unknown to me. It turned out to be a very minor effect (1-2% of execution time) and hard to tune; with lots of parameters, it's best to make a local function, with just a few it's best to pass the parameters round. I see. I'm a little surprised though. I thought that performing SAT (static argument transformation) would make GHC much keener on inlining the function. My expectation was that there would be some gain from that. Just as a comment I can add that in my paper Shortcut fusion for accumulating parameters zip-like functions in last year's ICFP I performed SAT by hand on the definition of unfoldr and foldl' in order to make all the inlining happen in the way I wanted. Without this I would either have to rely on the compiler performing SAT or there would be no fusion. My gut feeling (which ofcourse can be wrong) is that SAT can play an important role when transforming programs. /Josef ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD + FIFO pipes
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
