FFI, safe vs unsafe

[John Meacham]

On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
> What are the conclusions of this thread?
> 
> I think, but correct me if I'm wrong, that the eventual outcome was:
> 
>  - concurrent reentrant should be supported, because it is not 
>    significantly more difficult to implement than just concurrent.

It wasn't a difficulty of implementation issue, it was whether there
were unavoidable performance traeoffs. I have no problem with very
difficult things if they are well specified and don't require
unreasonable concessions elsewhere in the design.

in any case, I think the __thread local storage trick makes this fast
enough to implement everywhere and there were strong arguments for not
having it causing issues for library developers.


>  - the different varieties of foreign call should all be identifiable,
>    because there are efficiency gains to be had in some implementations.

indeed. 

>  - the default should be... concurrent reentrant, presumably, because
>    that is the safest.  (so we need to invert the notation).

well, I like to reserve the word 'safe' for things that might crash the
runtime, unsafePerformIO, so making things nonconcurrent isn't so much
something unsafe as a decision. I'd prefer nonconcurrent be the default
because it is the much more common case and is just as safe in that
regard IMHO.

> So, can I go ahead and update the wiki?  I'll try to record the
> rationale from the discussion too.

sure.

> I'd like to pull out something from the discussion that got a bit lost
> in the swamp: the primary use case we have for concurrent reentrant is
> for calling the main loop of a GUI library.  The main loop usually never
> returns (at least, not until the application exits), hence concurrent,
> and it needs to invoke callbacks, hence reentrant.

this is a pain. (making various libraries main loops play nice
together). not that it is a haskell specific problem though I guess we
have to deal with it.  I was thikning of using something like
http://liboop.org/ internally in jhc.. but am not sure and would prefer
a pure haskell solution without compelling reason to do otherwise.


        John

-- 
John Meacham - ⑆repetae.net⑆john⑈