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:
After thinking about it a little, I'm not even ready to bet that "safe" wouldHowever, at the time I don't think we appreciated the implementation diffiulties arising from "safe".
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:
I like that. Did I already mention that I think that the safest variant shouldTo be completely explicit, I think that increasing the safety level of any foreign import should never make the program fail.
be the default? ;-)
| [...]Yes. All but the last one also go away when we keep the distinction, but say that
| 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?
"increasing the safety level [...] should never make the program fail".
Cheers,
Wolfgang
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi