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

[Claus Reinke]

>> 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)? 
>If Haskell' includes concurrency then of course it must say something
>about the behaviour of foreign calls with respect to concurrency (if
>that's what you mean by "threadability").  Is that what you're asking?

yes. I'm all for Haskell' having both ffi and concurrency, but that means
that the feature interactions have to be investigated. I know you made a
start on that, so I was just pointing out some further corners that may
need looking into:

- if foreign code is used in Haskell' scheduling, what properties of
    the foreign code need to be specified, how does long-running
    foreign code interact with the scheduler, and are the current 
    annotations sufficient for all that?

- if Haskell' code involving concurrency is foreign exported, what 
    does that mean? does it work out of the box, or what are the
    limitations?

>> 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?
>I'm sorry, I completely fail to see what you're getting at with this
>line of discussion.  Could you say in more detail how you expect to
>provide access to concurrency via the FFI?  And what the point of it is?
>(it's not obvious how to foreign export forkIO, for example).

I was looking for a practical example involving concurrency and ffi
in such a way as to expose some of the questions that need to be
answered. you're mentioning forkIO, so that's an example of such
questions: why shouldn't we be able to foreign export that? it's just
a bit of Haskell functionality with a library API, isn't it?

the example is practical, yet rather complex: Haskell foreign exporting
concurrency, foreign code that uses the Haskell concurrency library
api also being used as callbacks in things like forkIO. will the 
combination of concurrency and ffi envisioned for Haskell' be up to
that kind of thing or not?

without looking at the current specs, just naively seeing the libraries
Control.Concurrent and Control.Concurrent.MVar, and knowing
that there is such a thing as foreign export, I would expect to be
able to apply the latter to the former. the MVars would hold C
data not interpreted on the Haskell side (just stored and passed 
around), and the C code would appear as IO a on the Haskell 
side, as far as forkIO is concerned. I admit this is a naive view, 
and I particularly avoided checking the specs first, but why 
should Haskell' programmers not expect this to work, if the
language has both concurrency and ffi?

cheers,
claus