apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: apr_dso_handle_close ?
Date Wed, 18 Apr 2001 03:38:42 GMT

> > 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 Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message