Concurrency, FFI status

[John Meacham]

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⑈