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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
