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.
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.
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.
David