Re: Question about LuaJIT's future FFI/Struct Extension

[Doug Currie <doug.currie@...>]

On Mar 17, 2010, at 3:14 PM, Mike Pall wrote:

> But let's turn that around: what would you (not just you, Duncan)
> like to see in such an API? What would you like to do with it?
> What might help to make it simpler and easier to maintain?
> Real-life examples are preferred of course.
> 
> It's easier to bind C/C++ code to Lua than to other languages. But
> from some mailing list postings, I get the impression it's still
> like a black art for newbies. And it gets really messy once you
> need anything not-so-simple: C++ OO vs. Lua OO, cross-language
> inheritance, GC/memory management interactions, integrating
> exceptions etc. ... I'm sure this list is incomplete.

Callbacks to Lua are always painful: where is the Lua thread pointer kept? Is the thread still live? Often it doesn't matter: the callback just needs to run the Lua function on some stack. The callback can be  synchronous (where a Lua call into C code ultimately triggered the callback) or asynchronous (where another native thread or signal wants to run Lua code). The FFI should be able to construct the callback glue based on a specification, at least for the synchronous case.

C arrays as arguments or results - userdata or convert to tables? Both options are useful.

Per-thread context (thread local storage) for libraries, per my gem, could be easier.

Integration of new data types implemented as userdata can be awkward: parsing, conversion to/from built-in types, comparison with built-in types, etc.

e