apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: apr_dso_handle_close ?
Date Wed, 18 Apr 2001 03:17:19 GMT
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

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.

View raw message