OT: 'best' dynamic language

[Manlio Perillo]

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
>> this.
> 
> 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
> globals).
> 
> 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
> 
> Cheers,
> 
> -Adrian
> 


Regards  Manlio Perillo