Re: LuaJIT 2 ffi (casting / force hotpath)

[CrazyButcher <crazybutcher@...>]

Thanks for the quick information, the lib["func"] was me not thinking
in Lua terms ;)
despite not being commented, your code snippets from other mailing
list posts and the source are actually quite readable.

looking at the source I also noticed that all individual enums become global

ffi.cdef "enum Type {TA,TB,TC};"
will mean there is
ffi.C.TA (returning 0)
ffi.C.TB (returning 1) and so on

it's also nice one cannot overwrite these things!

this is certainly C style as it just becomes an int. But for
type-safety it would be kind of cool if one cannot pass a number to a
function "someFunc(Type)" but has to use the real enum. Although, well
there is also cases where I hate c++ for not taking an int ;)

I also was able to create an cdata object of "Type", but I guess the
main use case for that is if a pointer to Type was required as
function argument? Otherwise using numbers would be fine or? I didn't
try with a enum function argument yet, but I'd expect it to not take
an int*, but insist on Type*

in a c++ mode one could think of using
ffi.CPP.Type.TA

design wise a ffi.CPP and ffi.cppdef with namespaces and such would
probably be the cleaner way to go about and rather keep the C mode
like C works.

--

Regarding the callbacks, the only way to get this for now is having a
regular C function, which then calls the lua runtime to push
arguments, and retrieves returns afterwards?

But how would I be able to convert the cdata args and returns of a
function safely to what the C function must deal with.

static luaFunction;
int assignFunc(lua_State* L)
{
  // get func from stack and store it
}

Type* dummyFunc(OtherType *)
{
  // set up Lua State for luaFunction
  ..
  // call luaFunction
  ..
  // get return
}

For that to work, you would need to expose your cdata conversion
handling via LuaJIT's C Api somehow or?

On the other that approach is flawed as we would need to know how many
callbacks we need in advance (or just create a bunch automatically,
it's a hack dll anyway)

probably has been answered before but luajit2 is thread-safe, or? A
brief look at luaL_newstate shows per LuaState thread-safe allocators.

-Christoph