lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Jan 31, 2011 at 4:56 AM, Mike Pall <> wrote:
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