ghci and ghc -threaded broken with pipes & forking
marlowsd at gmail.com
Thu Dec 11 05:53:56 EST 2008
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:
>> 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
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!
More information about the Glasgow-haskell-users