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.
I've been assuming that Haskell' was intended to encompass a wide range of implementations. If that's the case, the key point is that a Haskell' module that does not use concurrency, but is thread-safe, ought to work with non-concurrent implementations too.
To make that work, we'd need two interfaces: * one for applications that make use of concurrency. This would be unavailable on some implementations. * one for thread-safe use of state. This would be available on all implementations, and authors not requiring concurrency would be encouraged to use it for maximum portability.
Sure, I think this is a point on which we're all agreed. The portable interface could be Control.Concurrent.MVar, perhaps. Cheers, Simon