Re: Lua and multi-threaded FastCGI servers

[Peter Colson <pcolson@...>]

On 04/03/2005, at 7:24 PM, Wim Couwenberg wrote:

> > - Is LuaThreads a separate package or is it the coroutines facility 
> > within standard
> > Lua for doing non-pre-emptive threading in a Lua script? Does it sit 
> > on top
> > of Posix threads (saw references to LuaThreads on top of eCos threads
> > elsewhere)?
>
> I'm not knowledgable on LuaThreads (I'm sure Diego will answer your 
> question).  However, from my own experience and what I read on this 
> list, it is probably not a good idea to run several pre-emptive 
> threads on one and the same Lua state.  The locking overhead can be 
> quite high.  I'd stick with a Lua state per thread and handle 
> marshalling of any data yourself.

Yes agree with this - it feels safer to me too.

> > - I can see a lua_newthread() API that can be called from C - is this 
> > an
> > alternative to creating my own Posix thread and then lua_open()'ing a 
> > new
> > Lua VM within that thread (which was what I was trying to do now)?
>
> No.  lua_newthread is for coroutine support.  It creates a "Lua 
> thread" (essentially a separate call stack) as a data structure in a 
> Lua state.  It does not offer or support pre-emptive threading 
> automatically (i.e. you still need some extension).  There are endless 
> discussions about coroutines on this list and they are explained in 
> the manual and in PIL.

OK, at this point I think the threading infrastructure will remain 
outside of Lua anyway due to pre-existing FastCGI code in C.

> > - lua_set/gettable(L, LUA_GLOBALSINDEX) vs. lua_set/getglobal(L, 
> > "global_id")
> > as a way of setting/getting globals in a Lua VM. Are these equivalent 
> > or
> > have I confused two concepts?
>
> Equivalent.  The _global versions save you an additional push call.

OK, and this is working nicely for me now.

> > - Also, lua_pcall vs. lua_cpcall. lua_cpcall seems to be the 
> > preferred method
> > for invoking a Lua script and not having the calling program 
> > terminate if an
> > error occurs since the C function passed to lua_cpcall will return to 
> > the
> > function calling lua_cpcall in the event of an error?
>
> Depends on your situation.  To safely call a function on the Lua stack 
> lua_pcall is just what you'll need.

Shall stick with pcall then, it's working fine at the moment.


Regards,
Peter Colson.