David Greenspan wrote:
> Now there's just the callback situation -- I thought Objective-C's
> message-passing would insulate me, that I could have one C function that
> would be the implementation of every selector I need to implement, and I
> could do my own dispatching. However, it seems that calling conventions
> still apply through the msgSend wrapper, so I'm not sure how to avoid having
> multiple C forwarders for different function types.
That's why msgSend is written in assembler. All argument registers
are preserved and the stack is left untouched before it tail-calls
the receiver. It only needs variants for FP returns or struct
returns, depending on the target platform. Have a look at the
sources -- I guess you could do something similar.
What's missing, though, is an implementation of the receiving end of the calling convention given the argument types, which is what I'm using the C compiler for when I write a forwarder that passes the arguments to Lua. Unless FFI already provides a way to create a C function from Lua.
> Perhaps I just have to
> wait for FFI to get callbacks to clean up that part of my code.
Probably. But I still have no good solution that avoids keeping
callbacks alive forever (slowly chewing up memory) without
resorting to manual lifetime management.
I would never expect a reference from native code to keep an object alive, so I would be ok with a system where I have to retain a reference to the callback, if it helps. Or couldn't there be a lazily-created C function wrapper retained by each Lua function? I may be missing the real crux of the issue. But to me the feature is being able to create something C-callable from Lua (or even programmatically from C for that matter), in case the "callbacks" feature involves more than that.
-- David
