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⑈ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime