safe and threadsafe

[Wolfgang Thaller]

Simon Peyton-Jones wrote:
> That's a positive advantage, provided there isn't a massive efficiency
> cost.  I'm all for nuking 'threadsafe' if we can!

Simon Marlow wrote:
> However, at the time I don't think we appreciated the implementation
> diffiulties arising from "safe".

After thinking about it a little, I'm not even ready to bet that "safe" 
would
be that much faster than "threadsafe" for GHC...

Safe call-out can probably be optimized by not sending a signal
to a worker thread. (Worker thread spawning happens only the first time,
so it is not an issue).
Afterwards, we could immediately re-grab the "Capability" (without 
waiting)
and reenter the RTS, _unless_ there has been a call-in in the meantime.
We cannot do call-ins the same way as in the non-threaded RTS,
because when "threadsafe" calls are around, we cannot return from
schedule() (execution might have moved to a different worker).
After a call-in, the worker thread that was used to handle the call-in 
would
still hold the capability and continue executing haskell code, so a 
safe call
would have turned threadsafe. This might be difficult to prevent in 
practice.

Also, the biggest piece of wasted performance that's currently lying 
around
there is the locking for call-ins: give me a version of allocate that I 
can safely
call with only the sched_mutex held (while STG code is executing in 
another
thread), and I can cut the number of context switches for a call-in in 
half.

Simon PJ wrote:
> To be completely explicit, I think that increasing the safety level of
> any foreign import should never make the program fail.

I like that. Did I already mention that I think that the safest variant 
should
be the default? ;-)

> | [...]
> | What should happen when C code running in a separate OS thread calls 
> a
> | foreign exported
> | function while the Haskell Runtime is blocked on a safe call?
>
> Would all these questions go away if we made safe=threadsafe?

Yes. All but the last one also go away when we keep the distinction, 
but say that
"increasing the safety level [...] should never make the program fail".


Cheers,
	Wolfgang