important news: refocusing discussion
simonmar at microsoft.com
Mon Mar 27 03:36:28 EST 2006
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.
More information about the Haskell-prime