lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


takehiro iyatomi wrote:
> 1. according to src/lcoco.c,
> #define COCO_MIN_CSTACKSIZE             (32768+4096)
> coco consumes at least 36K memory for each coroutine. can it be smaller?
> because for my project, it is possible that 10k+ coroutine run concurrently
> and seldom uses stacks. so I want to reduce memory usage.

You can try to reduce it, but you must watch out for silent memory
corruptions. E.g. quite a few libc functions use a lot of stack
space. You can try to experimentally derive the lowest value: find
out the highest value where it crashes and then add some headroom
for safety. It's still a bit like Russian Roulette. :-)

In any case, 10K+ coroutines are not the best use case for Coco.
While it's convenient to be able to yield and resume to C code,
the C stacks are rather costly. You might be better off in the
long term to convert to non-blocking C functions and wrap some Lua
code around them which does the yield instead.

The memory overhead of plain Lua coroutines is much lower:

  http://lua-users.org/lists/lua-l/2009-11/msg00000.html
  [The numbers for Lua+Coco are the same as for LuaJIT 1.1.]

The memory overhead is the main reason why I dropped the C stack
switching for LuaJIT 2.x. But, of course that doesn't allow you to
yield/resume directly in C anymore. But a Lua wrapper function is
of course less costly in LuaJIT.

> 2. this peace of code in lcoco.c
> #ifndef COCO_DISABLE_EARLY_FREE
>   if (L->status != LUA_YIELD) {
>     COCO_FREE(L)
>   }
> #endif
> I define COCO_DISABLE_EARLY_FREE and test, it seems work fine.
> so is there any reason that this definition is disabled by default? if it is
> enabled, we can reuse coroutine without having any overhead of additional
> malloc/free.

It's not set by default because it delays freeing the C stack
until the next GC. Most users don't recycle coroutines, so would
rather have the memory freed early. If you plan to recycle
coroutines you should definitely use the define.

--Mike