safe and threadsafe

[Manuel M T Chakravarty]

"Simon Marlow" <simonmar at microsoft.com> wrote,

> > 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 extra efficiency was not at the expense of
> > correctness.
> > 
> > To be completely explicit, I think that increasing the safety level of
> > any foreign import should never make the program fail.
> 
> If I recall correctly, the motivation for keeping "safe" was that we
> wanted to be able to make calls into non-threadsafe C libraries.  Which,
> incedentally, would break the property that Simon mentions above: a
> non-threadsafe library would *require* foreign imports to be labelled
> "safe" rather than "threadsafe".
> 
> However, at the time I don't think we appreciated the implementation
> diffiulties arising from "safe".  Also, Wolfgang has pointed out that
> you can simulate serialisation in Haskell using MVars.

With the MVar solution, I am worried that it will add a lot
of extra code to large libraries like Gtk+HS, where every
single of the hundreds of functions would need to be
protected by an MVar.  Hence, to answer Wolfgang's question

Wolfgang Thaller <wolfgang.thaller at gmx.net> wrote,

> Are safe calls _guaranteed_ to block all other haskell threads and 
> prevent garbage collection,
> or is that an implementation detail? Are unsafe calls guaranteed to do 
> so?

My intention was that safe and unsafe calls are guaranteed
to block Haskell threads.  Consequently, safe and threadsafe
shouldn't be collapsed into one.

Reading Wolfgang's description of how the various policies
are implemented, I actually got a bit worried about
efficiency in general.  How much more expensive than a
vanilla function call is an unsafe, a safe, and a threadsafe
call in the threaded RTS at the moment?

Cheers,
Manuel