Re: LuaJIT: is Coco a requirement?

[Mike Pall <mikelu-0710@...>]

Hi,

Grellier, Thierry wrote:
> I know that luaJIT uses Coco: could it be possible to do without it?

For LuaJIT 1.x: well, yes, if you don't use yield() ... :-)

> - I may have scalability issue (100 thousands of coroutines, so if they
> also have a C stack allocated...)

LuaJIT 2.x will use a hybrid model. No C stack is allocated for
"regular" execution. This includes pcall() (because it's no
longer implemented as a C function), iterators and metamethods.

Q: Which of the extra features of Coco/LuaJIT are useful for you?
   1. yield() across pcall().
   2. yield() across iterators (for x in my_iter() do ...).
   3. yield() across metamethods (__index, __add, ...).
   4. yield() across callbacks from (your own) C functions.
   5. lua_yield() from (your own) C functions and resume back to them.

[I'm interested in feedback from all users.]

An extra C stack per coroutine is only required in use cases
4 and 5. One needs to explicitly set the required C stack size
when creating each coroutine or these features are disabled
(LuaJIT 1.x allocated a C stack for every coroutine by default).

> - I'd like to make the lua state persistent and would then like to be
> sure that there is no C stack to restore, because I have no reflexivity
> for it.

This needs some hacking into the internals of the VM. But this
applies just as much to Lua as LuaJIT 2.x. It's rather tricky in
LuaJIT 1.x because of the liberal use of the C stack.

> Not embedding luaJIT yet (I need bitwise operators), but could be
> interested in.

I'm leaning towards bundling a standard library for bitwise
_functions_ (not operators) in LuaJIT 2.x. Maybe not in the first
release, though. A bundled library has the advantage that the
compiler knows about it and can generate efficient code for it.

Q: Is 32 bit bitwise arithmetic (using the standard number type)
   sufficient or would you rather have fixed length bitvectors
   (heap allocated)? Or both?

Bye,
     Mike