> > 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.
I would like David Reid and Brian Havard (and maybe Fred Sanchez and either Bill)to sign off on the change before we make it. I'm being paranoid about those platforms that I don't know really well, and I know I am, but I really don't want to be wrong about this change. As long as those guys are comfortable with it, then +1 for making the change. Of course, since it could be a long time before they all respond, I would simply ask that we wait a day or two longer, and the commit message makes it clear that this change can be removed if it causes any problems on some platforms. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
