Mod_lua "per thread" states/scopes

[Brian Akins <br...@akins.org>]

I'm hacking on getting the former work I did for mod_wombat to have
per-thread lua states/scopes into mod_lua.  I like the new pool approach.
My main reason for this is we have some code that runs on almost every
request that we are careful about variable scope, etc that the overhead of
creating a new state every time would just kill performance.

Hopefully have some code in next couple of days...

Re: Mod_lua "per thread" states/scopes

[Brian McCallister <br...@skife.org>]

Thanks, I will poke into it as soon as I have a chance!

On Thu, Feb 5, 2009 at 9:20 AM, Brian Akins <br...@akins.org> wrote:
> Here's a patch just to give you an idea of what I'm thinking.  It compiled.
> This is more to get some ideas going to see how/iff this fits into mod_lua.
>
> The biggest issue is that the package_paths are per_dir and in post_config,
> you can't really get at those in a useful way.  I "precompile" all of the
> server scoped handlers in post_config so that there is no worry about that
> once we start taking requests.
>
> This just makes an array of pools sized at thread_limit, so that basically
> each thread has it's own pool.  I use the connection->id to determine what
> thread a request is running in, bcs there is no real way to get at that.  I
> used worker here, so this may not work anywhere else as it's tied to how
> worked calculated the connection->id.  Since the pool is per thread, we
> don't have to worry about any locking (in worker at least).
>
> --bakins
>
>

Re: Mod_lua "per thread" states/scopes

[Brian Akins <br...@akins.org>]

Here's a patch just to give you an idea of what I'm thinking.  It compiled.
This is more to get some ideas going to see how/iff this fits into mod_lua.

The biggest issue is that the package_paths are per_dir and in post_config,
you can't really get at those in a useful way.  I "precompile" all of the
server scoped handlers in post_config so that there is no worry about that
once we start taking requests.

This just makes an array of pools sized at thread_limit, so that basically
each thread has it's own pool.  I use the connection->id to determine what
thread a request is running in, bcs there is no real way to get at that.  I
used worker here, so this may not work anywhere else as it's tied to how
worked calculated the connection->id.  Since the pool is per thread, we
don't have to worry about any locking (in worker at least).

--bakins