On Tue, 17 Apr 2001, Greg Stein wrote: > I'm sorry, but this is just feeling wrong. > > "Perl opens these DSOs for me, but won't close them. I can't patch Perl to > do it for me... lessee... oh! I can patch APR! Yah, that's it!"
i never said Perl couldn't be patched. but if i patch Perl (and i will), i'd still need to keep a duplicate version of the functionality in mod_perl until Perl 5.6.2 is released, which will be ages from now. > I'm not comfortable with APR being a workaround for other problems. its Apache-Portable-Runtime, it is supposed to solve portabilty problems. this is a portabilty problem. i am porting Perl to Apache, or Apache to Perl depending on how you look at it. there is something portable in apr that solves the problem but is private, all i want todo is expose it. > APR has a design: you build an apr_FOO_t and use that. We do have a notion > of getting/setting a native FOO into those structures. > > Why are people crying about allocation performance? When you create a pool, > you get an 8k block. Allocations out of that first 8k are *FAST* (when you > go past it, then you need to get more from the system... maybe). And we're > talking about 8 (BeOS) to 16 (OS/2) bytes for these structures. You aren't > going to fill up that 8k of pool. > > Hell, if you have your own pool, and you need to unload 30 modules, you're > only going to consume 480 bytes. Tops. > > Effectively, there is no "allocation" overhead, so that isn't a valid reason > to start moving outside of the standard apr_FOO_t design of APR. For a > workaround because Perl doesn't give you a function. and what about the mutex lock on alloc_mutex? and all the extra function calls i mentioned before: "also with apr_dso_make there'd also 6 * num_dsos_to_close extra function calls, apr_dso_make, apr_pcalloc, apr_pool_cleanup_register, apr_dso_unload, apr_pool_cleanup_run, apr_pool_cleanup_kill. not to mention having to loop over p->cleanups * num_dsos_to_close in apr_pool_cleanup_kill." sure it might be minmal overhead, but it is overhead, period. a little here, a little there, this stuff adds up. but if the exposure of apr_dso_handle_close() isn't acceptable because it doesn't feel right, i guess apr_dso_make() or whatever will do the trick until a Perl is released with the proper interface.
