RE: Concurrency (was: RE: Re[2]: important news: refocusingdiscussion)
On 29 March 2006 10:16, John Meacham wrote:
On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:
(b) it is unlikely that Hugs or JHC will implement concurrency even if it goes into the standard
Well, if the standard is unimplemented for certain compilers, I think we need to work on the standard because that would be a deficiency of it. I would very much like to be able to write portable concurrent programs which doesn't necessarily mean GHC style concurrency or nothing.
given the choice between
1. a standard specifying something most people can't implement 2. a widely available but not mentioned in the standard extension
2 seems much more preferable and we should err on that side.
Fair enough - I take that as a vote for a concurrency addendum. I think it's a bit unfair to talk about "GHC-style concurrency". There are many different ways to implement exactly what GHC currently provides. In fact, we were very careful when designing it to ensure that this was the case: 1. one OS thread per Haskell thread, giant lock around the runtime 2. one OS thread for the runtime, fork OS threads for foreign calls 3. hybrid implementation with a pool of OS threads (GHC's implementation). You even mention another implementation that we hadn't considered: 4. one OS thread per Haskell thread but no lock around the runtime, with possibly repeated work. YHC uses (2), for reference. You're proposing (4) as one possibility for JHC. Cheers, Simon
On Wed, Mar 29, 2006 at 11:56:41AM +0100, Simon Marlow wrote:
Fair enough - I take that as a vote for a concurrency addendum.
Actually, I think there is a lot we can standardize in a portable way when it comes to concurrency without compromising the ability for any compiler to implement it and I think it would be very worthwhile to do so. in the report proper.
I think it's a bit unfair to talk about "GHC-style concurrency". There are many different ways to implement exactly what GHC currently provides. In fact, we were very careful when designing it to ensure that this was the case:
yeah, when I say GHC style concurrency, I mean the interface that ghc has. forkIO,MVar, etc... as opposed to event-loop, O'Haskell, expliticly scheduled, manual continuations, etc.. but I have been clumsy about whether I mean cooperative or fully-preemptive by GHC-style. I'll try to make that clear. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham:
On Wed, Mar 29, 2006 at 11:56:41AM +0100, Simon Marlow wrote:
Fair enough - I take that as a vote for a concurrency addendum.
Actually, I think there is a lot we can standardize in a portable way when it comes to concurrency without compromising the ability for any compiler to implement it and I think it would be very worthwhile to do so. in the report proper.
I think it's a bit unfair to talk about "GHC-style concurrency". There are many different ways to implement exactly what GHC currently provides. In fact, we were very careful when designing it to ensure that this was the case:
yeah, when I say GHC style concurrency, I mean the interface that ghc has. forkIO,MVar, etc... as opposed to event-loop, O'Haskell, expliticly scheduled, manual continuations, etc..
As I see it, it's really only GHC's API which is up for discussion for inclusion in Haskell', as we we decided that we largely want to go with already implemented and tested approaches. Manuel
participants (3)
-
John Meacham -
Manuel M T Chakravarty -
Simon Marlow