Pre-emptive or co-operative concurrency (was: Concurrency)

[Claus Reinke]

>GHC's SMP mode is truly preemptive, operations from multiple threads can
>be arbitrarily interleaved.  So let's stop saying that all known
>implementations are non-preemptive, please ;-)

but gladly, if that is the default!-) 

so if we take that hypothetical example of foreign exporting GHC's 
concurrency support, can we assume that the (IO a)s implemented in 
foreign code will be given their own OS thread when using that 
concurrency library? all of them, or only the non-atomic ones?

if, say, Hugs was to foreign import that library from GHC, its IO actions
wouldn't do much (GHC-side )allocation; and if Hugs was to import that
same library from YHC, it wouldn't do many (YHC-side) abstract machine
steps; etc.; we could try real time-slicing, but how would we suspend/restart
foreign code? so there doesn't seem to be much choice for integrating
foreign IO code into the schedule, other than giving it its own OS-thread;
of course, Hugs' IO actions may not be thread-safe, so that may not
be an option, either.

the point being: the FFI says something about how to integrate
foreign and Haskell memory management; should it also say something
about threadability of foreign code (wrt to scheduling, and wrt thread-safety)?

cheers,
claus

ps: Neil said:
>If all Haskell' prime implementations depend on "GHC the library",
>then do we really have many Haskell' prime implementations, or just a
>pile of wrappers around GHC?

are you implying that implementing external libraries in Haskell is
in any way inferior to implementing them in C?-)