Paul and I seem to be stepping on each others toes, so I want to settle on how lua_State (vm) management should work.
My opinion: * VMs are attached to apr pools. * A pool may have several VMs attached to it Each VM has a name, that name is part of the key in the pool userdata key. * Concurrency is up to 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. * One entry point to obtain VMs This is the apl_get_lua_state(..) function. It is passed the information required to either find, or create the needed lua_State. This is: - the lifecycle pool to which it is bound - the file name to define stuff in the lua_State - package load paths for the lua_State - package load paths for lua cmodules - a callback and baton to be invoked if the lua_State is created These can either be passed in as explicit arguments or as fields on a struct. The argument, as I see it, for the struct is that it allows adding new params without breaking API compatibility. The argument for seperate arguments is that it is more idiommatic and easier (less code) to call the function.
