On Tue, 10 Apr 2001, Greg Stein wrote: > I'm with Ryan. We don't need to write a cover for the underlying DSO close. > If you use APR's DSO stuff, then you can use its closing system.
we're not writing anything, just exposing functionality that is already in there, tucked away private. > Go patch Perl to add a cover for dlclose() since that is where you got the > handle. that is not useful for the moment, it will months before a new Perl is released. granted, that is not apr's problem, but apr can provide a solution much sooner. > I'd be fine with apr_dso_make(void *handle). [ back to the put vs make > discussion ] > > And piffle with the extra memory or speed with wrapping an apr_dso structure > around the handle [just to close it]. You're loading/unloading DSOs for > chrissakes. Perf just doesn't come into the picture. And I'm sure you've got > a pool that the apr_dso can go into, which is just about to get tossed after > you're done unloading DSOs. i am also closing these handles at request time, if an interpreter clone is knocked off due to PerlInterpMaxRequest or PerlInterpMaxSpare. don't forget, if a pool runs out of room, there's a mutex lock on alloc_mutex and malloc of 8k or whatever the default block size is. 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. if just the close part was exposed, i could do all this without using a pool and pile of extra function calls. it is a waste of resources, period. a waste of resources i can live with maybe, but don't tell me "perf just doesn't come into the picture". forget it, i will copy-n-paste my own portabilty layer together, patch Perl and wait a year or two till i can throw away the duplication.
