OT: 'best' dynamic language
manlio_perillo at libero.it
Sat Apr 26 21:42:35 MSD 2008
Adrian Perez ha scritto:
>> So, if I'm not wrong, you need to:
>> 1) Create a Lua state at the begin of the configuration phase
>> 2) Use this Lua state for precompiling all the Lua code in Nginx
>> 3) Finalize this Lua State at the end of configuration phase
>> 4) For each request create a new Lua state
>> 5) Use this Lua state for executing the precompiled script code
>> 6) Finalize the Lua state at the end of the request
>> But, again, I have never used Lua, I'm just reading the reference
>> manual and the source code, so better if a Lua developer can confirm
> I am using Lua in a World Domination™ project I can't talk about (and
> because it's fun! :-P)
May be it a game? ;-).
> That method will work, but I think it would be a bit faster not
> creating an entire VM on each request. Using lua_newthread you can fork
> off a new lua_State from an existing one, which will share the same
> globals but will have its own execution stack.
> You could do:
I was suggesting to use one VM per request since you can be sure that
there are no leaks, and you have more control.
As an example in the code I have posted, the file is not closed by just
running a cycle of the gc (but probabily I'm doing it in the wrong way).
Of course this should be a configurable parameter.
Using one VM per request means that one can not have persistent
connections to a database, as an example.
> 1. Create a lua_State before configuring (call it "main" state)
> 2. Load all Lua code into the "main" state.
> 3. Fork off a new "thread" with lua_newthread using the "main"
> lua_State as starting point when a request arrives.
How is this possible?
> 4. Run code into the forked "thread"
> 5. Let Lua garbage-collect the finished threads (or force a collection
> at the end of the request, or every n-th request, or whatever).
> I wrote "thread" with quotes because they are coroutines, not operating
> system "full-blown threads", they are very light and are implemented in
> the VM.
> One advantage of using coroutines is that they can yield and pass
> control asynchronously to Nginx. Coroutines can be resumed from C by
> using lua_resume.
Right, this is the main reason why I'm interested in Lua inside Nginx!
> Also, you can set up a fake global environment on a
> coroutine by using lua_setfenv (e.g. to only allow read access to
> Lua is wonderful in many ways, but what I like most is that it gives
> you a small set of features which can be used to achieve nearly
> everything, hehe.
> Just my two cents :D
Regards Manlio Perillo
More information about the nginx