On Thu, Mar 01, 2007 at 03:06:22PM +0000, Simon Marlow wrote: > Ok, what happens here is that in the forked process there is only a single > thread, the runtime kills all the other threads (as advertised). > Unfortunately this includes the I/O manager thread, so as soon as you do > some I/O in the forked process, you block.
Could it just revert to the nonthreaded IO model, or is that not within the scope of what's easily achievable with the threaded RTS? > On a more general note, forkProcess is known to be hairy - simply the fact > that it kills all the other threads in the system in the forked process > means that there's a good supply of means to shoot yourself in the foot, > even accidentally. John - perhaps there's another way to achieve what you > want? Right. Part of this problem may be one of documentation, and part of it rests with ghci. I have no need for threads in this program. And, in fact, as you said, threads are known to be hazardous when used in conjuntion with fork(). I have no interest in combining the to. The mechanics of signal propogation, file descriptor closing, etc. all get complicated. But it seems like there is not much choice with ghci. It appears to be built with the threaded RTS by default, and uses threads even though I never try to use threads with it. And there seems to be no way to turn it off. 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. Also, why does hGetContents not work, but hPutStr does? If the IO manager is dead, how does some IO still work? -- John _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
