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⑈