Concurrency, FFI status

[Simon Marlow]

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