[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Question about LuaJIT's future FFI/Struct Extension
- From: Doug Currie <doug.currie@...>
- Date: Wed, 17 Mar 2010 15:54:32 -0400
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.