FFI digest, Vol 1 #218 - 3 msgs

[George Russell]

Alastair Reid wrote:
[snip]
> I maintain that it is better to specify something simple and for GHC
> to document that it goes beyond the specification just as it does for
> unboxed types and the like.
I don't believe it's at all simple to specify that Haskell-land may not
be invoked at any time during the duration of some C function.  I'm not
even sure I know what "duration" means, in the presence of concurrency.
> 
> What's the point in going to all the effort of coming up with a common
> specification, all of us hacking our implementations to match the
> spec, endless arguing over details of the syntax, types, libraries,
> etc. if it doesn't achieve the goal of improving portability?  It
> would have been much easier if we'd left our (incompatible)
> implementations alone and not made an effort at defining a portable
> ffi spec.
People who only call C in a fairly simple way can still port their FFI
code between Hugs, GHC and NHC.  We all know that the current mechanism
is a huge improvement on the old non-portable ones.  However anyone who 
goes beyond this needs to be aware of elephant traps, and we should not 
expect them to read the specification in detail to do so.
> 
> >  Since I regard this caveat as an extremely
> > important one (for example, it severely limits the use of the FFI to
> > link to languages like Java, which also have their own GC)
> 
> I just want to note that I believe what you really need is a bunch of
> entrypoints into the runtime system not the ability to call Haskell
> code.
You also need entrypoints into (say) the Java runtime system, if you
are going to interact with Java.  Otherwise how are you going to tell
Java that one of your Haskell-provided callbacks must be delayed until
Hugs has finished its garbage-collection?  Or are you proposing that
anyone linking Hugs with Java must implement a lock (in Java) which
blocks every single callback to Hugs during Hugs GC's?

> 
> > it needs to be stated very clearly in the documentation of those
> > implementations which have it, rather than being left as an
> > embarassing hole which the user will only discover after a long and
> > painful analysis of the core-dumps.
> 
> Note that the problem is _exactly_ the same problem faced when using
> foreign functions which were declared using the 'unsafe' calling
> convention.  The only difference I can see is that unsafe calls are
> much more common so they are more of a problem.
The difference is that the "unsafe" calling convention uses the word "unsafe".
People who use features which are labelled "unsafe" may be assumed to be
aware of the elephant traps in the specification.  If they aren't it's their
own fault.

The reason most calls at the moment are unsafe is because the FFI has mostly
been used to link directly to C code in a fairly single-threaded way.  I'm not
sure even this is a good idea, since we can't go on assuming a single native
thread for much longer.  
[snip]