Bound Threads

[Wolfgang Thaller]

Simon Peyton-Jones wrote:

> [I've updated the "Semantics for foreign threads" document by
> re-ordering the sections a bit.  It'd benefit from having a bit more
> formal syntax.

That should be just a matter of copying from the ffi spec and adding an 
additional specialid... I had hoped to avoid learning how to use yet 
another TeX package...  but OK, I'll do that.

> No one has commented a single word on the operational
> semantics.  I don't know whether that's because it's so clear that no
> discussion is needed, or so opaque that no discussion is possible.]

I spent about half an hour staring at a printout, before I saw that it 
was all perfectly logical if I corrected one typo. Now I think there 
are no typos left in the formal semantics, so it should need less 
staring...

Anyway, do you think the proposal has been discussed enough for me to 
start working on a prototype implementation?

About threadsafe/safe:

> I think Wolfgang is saying that the apparent efficiency gain of not
> requiring thread-safety is illusory, [..]

In GHC, we might be able to save some time, but only for calls without 
call-back. As soon as there's a call-back, I can't see how we can save 
any time at all.

> [...] and so we can abolish the
> safe/threadsafe distinction.   I think that would be a very worthwhile
> gain. Does anyone disagree with this?

Kill it kill it kill it! We don't need that distinction.
However, it might be worthwhile for other implementations of Haskell, 
but we can't tell, because GHC is the only one that supports 
"threadsafe" at the moment. Does anyone plan to add support for 
multiple OS threads to Hugs or NHC?

If someone wants to keep "safe" in the FFI spec as an "optimization 
hint", then that's fine for me, but something has to be done about the 
misleading naming ("safe" is NOT SAFE) and an optimization hint should 
never be the default. And it should be made absolutely clear that an 
implementation may treat everything as "threadsafe".


Cheers,
Wolfgang