Simon Marlow:
On 26 March 2006 03:44, Ross Paterson wrote:
On Sat, Mar 25, 2006 at 05:31:04PM -0800, isaac jones wrote:
I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction.
I'm no expert on Hugs internals, and certainly not qualified to direct such an effort, but I don't have great hopes for it. Apart from the fact that Hugs is written in a legacy language and uses a quite a bit of global state, it also makes heavy use of the C stack, and any implementation that does that will have trouble, I think.
Yes, I don't see an easy way to do it. You could have one OS thread per Haskell thread (let the OS manage the separate C stacks), a giant lock around the interpreter (to protect all the global state), and explicit yield() from time to time to simulate pre-emption. This isn't too bad, but you still have to implement GC somehow, and hence traverse all the live C stacks, and that sounds tricky to me.
True, but so what? I mean, honestly, we should decide language features by their merit to applications and maturity. We should also take into account what the power/weight ratio of a feature is in terms of general implementation costs. But discussing the costs to one particular implementation that's already been stretched light years beyond what it originally was intended for, seems a bit much. Manuel