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?-)