ghci and ghc -threaded broken with pipes & forking
marlowsd at gmail.com
Thu Dec 11 11:49:42 EST 2008
John Goerzen wrote:
> Simon Marlow wrote:
>> 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 have, and it didn't work well. But it's been awhile, and I can't tell
> you anymore what version of GHC or what exactly the problem was. I was
> most certainly 6.8 or older. Once 6.10 hits Debian, I could test again
> there. But see below...
>> 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.
> That's probably an OK solution.
> I would also add: does the threaded RTS support all platforms? For
> instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't
> run there, but GHC does. If you drop the non-threaded RTS, does that
> mean that GHC doesn't work there at all?
If those platforms support threads, there's no reason why the threaded
RTS shouldn't work there. Also, GHCi should work on all platforms (even
unregisterised) these days, including the FFI if there's support in
libffi for that platform.
However, if if the threaded RTS doesn't work on a platform for some
reason, that doesn't prevent us just falling back to the non-threaded
RTS for that platform. Most things will still work.
>>> 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!
> Already done:
> (still open since Nov 2007)
That one is closed - fixed in 6.8.3 I think.
> There was also a thread here regarding problems with the threaded RTS:
> Not sure if that has been fixed, or was an error on my part, but see
> your reply at:
I did make a ticket for that:
That should be fixable - I'll put it on the current milestone.
More information about the Glasgow-haskell-users