FFI, safe vs unsafe

[Simon Marlow]

On 30 March 2006 11:42, John Meacham wrote:

> Although I was skeptical at the beginning that we could come up with a
> standard based on forkIO that could encompass both models without
> compromising performance or implementation flexability, I now think
> that we can! and that is good, because it means we won't need to make
> concurrency an addendum or just accept the fact that many
> haskell-prime implementations will be incomplete!

Which sounds like a win-win, but the concern Manuel rose earlier in this
thread still holds: namely that if we allow too much flexibility in the
standard, it becomes too hard to write portable applications.  Someone
coding for GHC will almost certainly not insert enough 'yield's to make
their program work properly on a cooperative implementation.  (hmm, I
wonder if GHC could be made to optionally behave like a cooperative
scheduler without too much effort.  That would help).

Still, I think this makes an interesting proposal.  Could you put it on
the wiki, perhaps replacing Proposal 3?

> A sticky point might be whether we say anything about duplicated work,
> however, the haskell report never really says anything about
> guarenteed sharing anyway so we can probably be silent on the matter.

Quite right, the standard doesn't need to mention this.

> we certainly shouldn't treat state-threads as second class or a
> "lesser" implementation of the standard though! they can often be
> faster than OS threads but with their own set of tradeoffs.
> 
> glossary:
> 
> OS threaded - ghc -threaded, context switching at arbitrary points,
> not necessarily under the control of the haskell runtime.
> 
> state-threading - hugs,jhc context switching at block-points chosen
> by the implementation and user via yield.
> 
> yhc is somewhere in between. basically state-threading, but with more
> context switching under the control of the yhc run-time.

I'm not sure I'd separate YHC from GHC.  They both satisfy the fairness
properties we talked about earlier, and from a programmer's point of
view would be indistinguishable (to a very close approximation).  It's
very hard to write a program that can tell them apart.

I think if the standard were to go in this direction, then it would be
helpful to establish two versions of the fairness properties: the strong
version that includes GHC/YHC, and a weaker version that also admits
Hugs (eg. the progress guarantee you mentioned earlier).  An
implementation would be required to say which of these it satisfies.

Cheers,
	Simon