lua-users home
lua-l archive

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


On Mon, Sep 15, 2008 at 3:04 AM, Sacado Sacado <sacado.sacado@gmail.com> wrote:
> The real big problem I can see as for now is memory use... Since the Lua
> interpreter is so small, I really can see it grow, kb after kb, every time a
> request is thrown.. This is frightening... :) But, even after tens of
> thousands of requests, the server uses less than 4MB. In nowadays'
> standards, this is nothing...

Implementing expiration of continuations (or sending them to the
client, see below) takes care of the memory issue, no? Unless you've
got a leak on your server. :-)

>> the 'real' solution is to use multi-shot continuations, not
>> available in Lua.
>
> Hmm... Sounds like a challenge :) I wonder if using Gut Steeles's algorithm
> for translating regular code into continuation-passing code would be
> feasible in Lua...

You can use pluto to serialize coroutines, and get multi-shot
continuations (you have to serialize before resuming it, of course :-)
). If your sessions are small you can even use the client to store
them for you, with hidden fields (like Microsoft does with ASP.NET
view state).

CPS translation is global... you have to translate *all* Lua code in
your application, libraries included, or you have the same problem you
have with coroutines and C code (you can't have any untranslated code
in your stack when you capture the continuation). Performance would be
much worse, also, with all the extra closures.

I remember someone posted a patch for a coroutine.clone to the list
once, check the archives; should be faster than using pluto when you
don't want the continuations to leave their parent VM.

> --
> sacado
>

--
Fabio Mascarenhas