Re: LuaJIT: is Coco a requirement?

[Mark Hamburg <mhamburg@...>]

on 10/25/07 6:27 AM, Mike Pall at mikelu-0710@mike.de wrote:

> 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?

First, note that our primary use of yield is for yielding back to the
scheduler rather than as part of a producer/consumer relationship or any of
the other common coroutine patterns.

>    1. yield() across pcall().

Very useful since pcall is also essential to error handling and clean up.

>    2. yield() across iterators (for x in my_iter() do ...).

Possibly useful. I could see writing server tasks that would iterate on a
work queue and the iterator itself might yield to the scheduler when the
queue was empty.

>    3. yield() across metamethods (__index, __add, ...).

In our experience doing too much work in __index and the like makes for
unpredictable program behavior. Programmers write code thinking that
something is just a field access or the moral equivalent thereof. Having it
yield control can be surprising. So, I don't feel a great need for yielding
across metamethods with the possible exception of __call.

>    4. yield() across callbacks from (your own) C functions.

We haven't needed this.

>    5. lua_yield() from (your own) C functions and resume back to them.

We haven't felt a need for this either.

Mark