On 11/01/2016 12:10, David Matthews wrote:
On 11/01/2016 08:34, Phil Clayton wrote:
I notice that the buildClosure<N>withAbi functions take the SML function
to call back to in the same tuple as the type of the callback arguments
and return value. Consequently the interface for constructing closures
using doesn't allow the same CIF to be used for multiple callbacks to
different SML functions (of the same type). Is that deliberate or could
there be some advantage in allowing that?
For the X86 at least; I can't say for the other architectures; the CIF
is very simple, consisting really of the types and a few flags. I had
expected that there would be some code there but there isn't. The
complicated part is when the closure is actually built and this involves
allocating memory with mmap so that it can be executable and building
the code that is passed as the C function. There's little to be gained
from reusing the CIF.
I looked at the code for FFI runtime call 55 (create a CIF) and there's
not a huge amount in there so it's not much overhead. I couldn't see
where the memory allocated for a CIF is freed though. (Probably not an
issue as the number of callback functions in an application is likely to
bounded, assuming that they are built only once by correct use of
buildClosure<N>.)
I have an interface where the CIF can be reused and was concerned that
doing so would be problematic, given that Foreign doesn't allow this.
It sounds like that isn't a problem though.
More importantly I wanted to steer users away from trying to create
closures on-the-fly because of the cost. Before the recent change to
use "buildClosureN" the calling mechanism implied that it was possible
to define a function that took, say an integer and an ML function, and
that the cost of passing the integer and the function were similar. In
practice that's not the case. They're only similar if the ML function
has already been wrapped as a C closure.
Yes, I see, hence the type 'a closure to represent a function whose
closure has been constructed.
I have a long-term plan to turn the buildCallN and buildClosureN
functions into something that is almost a mini-compiler that will
produce an interface function when it is applied. It may only be
possible to do that in certain cases and fall back to libffi in the
other cases. It's complicated because there are different ABIs for the
various combinations of X86-32/X86-64 and Unix/Windows.
Interesting - is that to make the FFI faster? I wonder if the
experiences of MLton would be useful for creating such an interface.
Phil
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
