This is just a "heads up" that I'm currently collating the current state of the discussion re: concurrency and the FFI, with a view to enumerating all the current issues with rationale on the wiki. It's getting to a state where I can't keep it all in my head at one time, and I think this will help us to move forward, and give others a chance to identify issues they would like to comment on. So just in case anyone else was considering large changes to the concurrency page on the wiki, please hold for a while. I should have it up by the end of the day. Cheers, Simon
I have now summarised the concurrency proposal status, here: http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Concurren cy I have tried to summarise the various points that have arisen during the discussion. If anyone feels they have been mis-paraphrased, or I have forgotten something, please feel free to edit, or send me some text for inclusion. I don't want to include long gobs of text in here, though: just summarise the main points, and if necessary link to relevant mailing list posts. Cheers, Simon
Good summary. I have made a few edits mainly to clarify what (I think) is being said. Under "cooperative or preemptive concurrency" I'd like someone two write down as precisely as possible what it means to say "the spec requires cooperative concurrency" or "the spec requires preemptive concurrency". That would set the context for the following choices Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Simon Marlow | Sent: 13 April 2006 14:42 | To: haskell-prime@haskell.org | Subject: Concurrency, FFI status | | I have now summarised the concurrency proposal status, here: | | | http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Concurren | cy | | I have tried to summarise the various points that have arisen during the | discussion. If anyone feels they have been mis-paraphrased, or I have | forgotten something, please feel free to edit, or send me some text for | inclusion. I don't want to include long gobs of text in here, though: | just summarise the main points, and if necessary link to relevant | mailing list posts. | | Cheers, | Simon | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://haskell.org/mailman/listinfo/haskell-prime
Simon Marlow:
I have now summarised the concurrency proposal status, here:
http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Concurren cy
I have tried to summarise the various points that have arisen during the discussion. If anyone feels they have been mis-paraphrased, or I have forgotten something, please feel free to edit, or send me some text for inclusion. I don't want to include long gobs of text in here, though: just summarise the main points, and if necessary link to relevant mailing list posts.
Good summary. Concerning the issue of preemptive versus cooperative concurrency, I still think cooperative concurrency is pretty useless. Is there any non-toy application that actually uses Hugs' current cooperative concurrency? Concerning the trouble of Hugs and Jhc to implement preemptive concurrency, IMHO that's a significant design flaw in these implementations. Preemptive concurrency is important for many applications and, if anything, will become more important with new architectures. Fundamental limits on being able to support this, fundamentally limit the application space. I'd rather not see that design flaw being transferred from these implementations to the language standard. Manuel
On Fri, Apr 21, 2006 at 10:01:51AM -0400, Manuel M T Chakravarty wrote:
Concerning the issue of preemptive versus cooperative concurrency, I still think cooperative concurrency is pretty useless. Is there any non-toy application that actually uses Hugs' current cooperative concurrency?
A couple of notes * How many non-toy applications can use hugs at all independent of concurrency? in a big concurrent app you are most likely going to need some ghc extension anyway. * It is unclear that pre-emptiveness even buys you much, standardwise. the only thing it can give over a cooperative one is better latency and even that can't be done as oleg pointed out without careful control of when lazy (pure) code gets evaluated, a similar situation to what one has to think about with cooperative implementations. * Hugs does not implement concurrency. A couple tests show that.
run1 = print "foo" >> run1 run2 = getLine >>= print >> run2
main = do forkIO run1 run2
this should continually print "foo" while waiting for input on any haskell-prime implementation due to the progress guarentee. it does not on hugs, this makes hugs concurrency not really concurrency IMHO, more like explicit coroutines with an odd interface. (which is the base of a good cooperative concurrent implementation, but not the same thing)
Concerning the trouble of Hugs and Jhc to implement preemptive concurrency, IMHO that's a significant design flaw in these implementations. Preemptive concurrency is important for many applications and, if anything, will become more important with new architectures. Fundamental limits on being able to support this, fundamentally limit the application space. I'd rather not see that design flaw being transferred from these implementations to the language standard.
It is not a design flaw, it is a choice. pre-emptiveness is not worth the effort given haskells other properties for many implementation models. It buys you very little, but implementing it can cause signifigant run-time overheads compared to cooperative ones for code that doesn't even use concurrency. I don't care about the difficulty of implementation, I care about the generated code and the ability to write standards compliant _and_ efficient haskell prime implementations. John -- John Meacham - ⑆repetae.net⑆john⑈
On 22 April 2006 04:03, John Meacham wrote:
On Fri, Apr 21, 2006 at 10:01:51AM -0400, Manuel M T Chakravarty wrote:
Concerning the issue of preemptive versus cooperative concurrency, I still think cooperative concurrency is pretty useless. Is there any non-toy application that actually uses Hugs' current cooperative concurrency?
A couple of notes
* How many non-toy applications can use hugs at all independent of concurrency? in a big concurrent app you are most likely going to need some ghc extension anyway.
* It is unclear that pre-emptiveness even buys you much, standardwise. the only thing it can give over a cooperative one is better latency and even that can't be done as oleg pointed out without careful control of when lazy (pure) code gets evaluated, a similar situation to what one has to think about with cooperative implementations.
I disagree that these two problems are equivalent in difficulty. In a preemptive implementation, I can execute any pure non-IO code in a thread without regard for how this affects the responsiveness of other threads. In a cooperative system, however, the programmer has to understand the performance characteristics of all the non-IO computations in the program, and if any might affect the latency beyond what is acceptable the entire code path has to be IO-monadised, or split up into sub-computations so that yields can be inserted. This affects the *entire program*. Including libraries that you didn't write and can't change. With preemptive concurrency, you just don't have to care about latency, it is under the control of the scheduler. The problem you are claiming is similar is the need for the programmer to understand the performance of non-IO code that executes while a resource is being held, such as an MVar. This happens much less frequently, it is a small fraction of the entire program. True it might happen in library code that you don't control, but you can legitimately claim that as a bug in the library, whereas claiming that a library of non-IO code is buggy because it is too slow and doesn't yield is unreasonable. Cheers, Simon
participants (4)
-
John Meacham -
Manuel M T Chakravarty -
Simon Marlow -
Simon Peyton-Jones