Re: nCcalls in the global state keeps increasing in 5.2

[Roberto Ierusalimschy <roberto@...>]

> > What release of Lua 5.1 are you using?
> 
> It's not what I use, it's what I used. I used 5.1.4.
> 
> > maybe you can
> > simply change the limit LUAI_MAXCCALLS in luaconf.h
> 
> That will simply postpone the error. Our system is designed to run for
> years and the ceiling will eventually be hit.

Only if you have an unlimited number of suspended threads, or if you are
killing suspended Lua threads with unreturned calls. If all threads
eventually terminate, the nCcall count will be eventually decremented.


> >From above bug report:
> 
> > Patch: The 'nCcalls' counter should be shared by all threads. (That is, it should be declared in the 'global_State' structure, not in 'lua_State'.)
> 
> What is the logic behind this statement?

See the reported bug. If all coroutines share a single thread (the
default in Lua), nested coroutines would overflow its stack.


> By moving nCcalls to the global structure, you in effect invalidate
> all design that map coroutines to native threads.
> 
> Is it my explanation of the problem that is not sufficient?
> Please let me know.

It was very clear.  But please understand that corotines (and Lua in
general) were designed to work with single threads. The possibility of
mapping coroutines to native threads has always been an adaptation.
The macros lua_lock/lua_unlock are a *concession* to multithreading;
Lua does not offer official support for that.

You can use Lua with multithreading (lots of people do), but you will
have to do some extra work with Lua's code base.  (There are other
caveats you may have to deal with, like the problem with references.)

-- Roberto