On 04/23/2013 11:49 PM, Guenter Knauf wrote: > Hi Daniel, > On 20.04.2013 08:58, Daniel Gruno wrote: >> Thanks for the invaluable help, it's really good knowing there's someone >> else taking such an interest in this project! :) I hope that someday we >> can shed mod_lua of its experimental status and people won't think me a >> crazy person for recommending it left and right ;) > naa, I find the module useful too for all sorts of smaller tasks as well > as special httpd things which otherwise can only be done with a C module > I believe ... > now since I looked a bit at the code here and there I think there are > some things which we should fix over the next months ... > > 1) the code formatting is not yet at our standard > 2) the 'apache2' module does pollute the global table, and at 1st glance > with my limited Lua experience I dont see why this happens; I've tested > with other dynamically loaded modules like geoip, socket and apr (yeah, > there exists a *very* *great* APR binding! [1]), and they all only > create their own table and nothing global; it would be nice if we could > either teach the apache2 module to behave same, or at least make it > prelinked/preloaded and let it only plug in when enabled via 'require'. > See attached script which shows what I mean ... > 3) Since there exists a well done and well functioning APR binding we > should probably consider to add some code to mod_lua so that its > possible to prelink/preload this APR binding once at module start > instead of loading it from every script again and again ... > if we would agree on that we could even ditch a bunch of the recent APR > adds, thus making mod_lua itself cleaner / smaller again + we would get > almost the full power of APR into mod_lua ... > > Gün. > > [1] http://peterodding.com/code/lua/apr/
Firstly, You can already pre-load and keep libraries persistent by doing a simple check: if not apr then apr = require "apr" end Let's not reinvent the wheel ;) Secondly, I think the APR bindings Peter made are great for standalone applications, but not for mod_lua. The reason for this is that the APR bindings allocate memory from a self-created global pool that is not tied into the request_rec structure, and thus NOT freed when the request is done, or when the VM is destroyed for that matter (it was like this the last time I checked), so if you use it, you'll most likely end up with a very large memory leak at some point, which is the reason why I discourage people from using it for mod_lua. It might be that it's changed from the last time I checked the source code, and if so, do correct me :) Thirdly, this would require users to download, compile and install the module (some may not even trust a third party provider), which goes against what I've been trying to achive; That users can pick up mod_lua, use it, and not have to worry about basic functionality missing. People want basic file handling, database access and some string manipulations from the get go, and don't wanna worry about having to install additional third party ibraries in order to make it work. I appreciate your thought on making mod_lua leaner, but I respectfully disagree that we should cut out these functions from it. I also have my own APR library called lua_apr, but I don't use it, as it doesn't tie into the memory pool that we use. As to performance, the addition of these functions into the request_rec structure has no significant impact on that. If you use a per-thread VM (which I recommend), the memory and cpu overhead is to tiny, it won't even register in a stress test. If you can point to anywhere that needs a formatting change, please do so, and I'll see to it that it's properly formatted. I did a major overhaul of my own contributions a while back, but there may still be some old code that needs changing ;) Yes, the apache2 table 'pollutes' the global table, but that has its advantages, and it's really not a big deal in my view. IF we want it to be leaner, we could tuck it into the request_rec object, so it'd be fx: function handle(r) do_stuff() return r.OK end With regards, Daniel.
