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
> I don't think it was ever the intention that 'safe' should have a
> guaranteed serialisation property. I think the idea was that
> 'threadsafe' was the most desirable, with 'safe' and 'unsafe' only
> available for use if you wanted more efficiency and had some separate
> guarantees that the extr
Folks
There was a spirited debate about the relationship between native OS
threads and Haskell threads. I got very confused. To clear up my
brain, Simon and I wrote a little operational semantics that tries to
make precise what is going on. It's in CVS as
haskell-report/ffi/threads.tex
| I have recently spent some time improving GHC's support for
| "threadsafe" foreign calls.
| As a side effect of fixing a crashing bug, I made "safe" behave in
| exactly the same way as "threadsafe".
That's a positive advantage, provided there isn't a massive efficiency
cost. I'm all for nuki
