On Feb 6, 2009, at 12:17 AM, Brian McCallister wrote:
* VMs are attached to apr pools.
+1
* Concurrency is up to the client
What are you defining as "the client"?
We should not expose configuration options which will create concurrency issues, such as attaching a VM to the server_rec pool. It is very possible for someone to programmatically use the module to do things like that, but if they do any locking or resource pooling is up to them.
Sure, bcs attaching to server_rec pool is silly. However, we do, IMO, need a way to have some other way besides r->pool in stock mod_lua. This is just too slow for a lot of things.
* One entry point to obtain VMs
+1. I personally do not like exposing tons of struct info, but I'm -0 on that.
We want to be able to get back to "stock" mod_lua, but it's just too darned slow right now :( Having some type of per-allocation and long lived LuaStates helps this allot. All the C stuff is done that way (in memory once, ran many times) and I'd like to be able to do the Lua stuff the same way without having to bolt on yet another bakins- specific module.
OT: toying with lua server pages :)
