At Thu, 1 Mar 2007 11:38:54 -0600, John Goerzen wrote: > > On Thu, Mar 01, 2007 at 04:21:45PM +0000, Simon Marlow wrote: > > >Between that and the lack of support for forkProcess in Hugs, this > > >renders anything that needs to fork and then do I/O as being usable only > > >in GHC-compiled code. Which is sub-optimal, but livable anyway. > > > > I guess I'm really wondering why you need to fork and do I/O at all. Can > > you describe the problem at a higher level? > > I am, for all intents and purposes, writing what amounts to a simple > shell.
The neat thing about the library is that external commands and haskell code can be freely intermixed, and are uniformly handled. For example, in this pipeline, r <- runS ("ls -l" -|- "grep i" -|- wcL ) wcL is a simple haskell function: wcL :: [String] -> [String] wcL inp = [show $ genericLength inp] The HSH library just creates some pipes to hook the processes together, and then forks of ls, grep, and wcL as seperate processes. The advantage of this scheme is that once the pipeline is started, everything behaves the same way it would if you had run the bash command: $ ls -l | grep i | wcL So, you get very familiar behaviour/performance from a shell scripting point of view. But, you also get to easily stick haskell functions in your pipeline. Poking around with the full HSH code, I *think* I got pipelines that *only* called external commands working fine[1]. This seems logical, since the external commands do not care about the Haskell I/O manager at all. So, perhaps you can have an alternate version of 'instance ShellCommand (String -> IO String)' that gets used for -threaded that uses forkOS instead of forkProcess. All of the external commands would still be forked into seperate processes, but all of the haskell commands would run in the same threaded process. Obviously, you would have to fake the return code, but it looks like that should be feasible. Some open questions are: a) how do you detect that you are running in the threaded RTS b) can you have the linker pick the correct version at link time, so that you do not have to have a compile-time check. Of course, a compile time check might only have to be done once, so the overhead would not be significant. j. [1] In fact, they may work fine out of the box, I haven't tested that. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users