John Goerzen wrote:
Brian B wrote:
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly.
I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression.
Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. Maintaining both versions of the RTS is certainly a burden, but I think it's one we have to carry, since there are still reasons to want both.
The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.)
If there's bugginess we need to get it fixed - please report those bugs! Cheers, Simon