Re: safe and threadsafe
Simon Marlow [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: safe and threadsafe
| 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 nuking 'threadsafe' if we can!
| 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? {In a SMP implementation,
| this might require additional interthread messaging}.
| 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?
| Some people have said that safe calls are intended for serializing
| access to foreign libraries
| that are not multithread-safe. I think that MVars should be used for
| such purposes. Blocking the
| entire Haskell Runtime for the duration of a safe call is overkill,
| but it's not always enough:
| Many old C libraries keep state in global variables from one call to
| the next.
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.
Simon
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
RE: safe and threadsafe
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. Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
safe and threadsafe
Hello Everyone,
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. Now I have to document it... :-(
I'm not very happy with the current definition of safety levels in the
FFI addendum
(section 3.3, Import Declarations). So before I write up somethhing for
the GHC user manual
explaining how GHC interprets it and why it does so, I'll try to
convince someone to change
or at least clarify the FFI spec a bit:
First, some things that are unclear:
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? {In a SMP implementation,
this might require additional interthread messaging}.
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?
Some more points:
In what way can a safe call be considered safe in a multithreaded
environment? After all
it may cause very hard-to-predict blocking. I think that threadsafe
should be the default,
where available.
It _may_ be possible to implement safe in a way that is slightly more
efficient than threadsafe,
however this is relatively hard to do correctly in the context of GHC,
and I don't expect a big
performance gain. But if that is possible, then safe would be just a
hint for increasing performance
by sacrificing some safety. It should be renamed to something else.
Ceterum censeo that
threadsafe should be the default.
Some people have said that safe calls are intended for serializing
access to foreign libraries
that are not multithread-safe. I think that MVars should be used for
such purposes. Blocking the
entire Haskell Runtime for the duration of a safe call is overkill,
but it's not always enough:
Many old C libraries keep state in global variables from one call to
the next.
Cheers,
Wolfgang
--
ceterum censeo invocationes tutas esse delendas.
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
