important news: refocusing discussion

[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.

> 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