apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr_dso_handle_close ?
Date Tue, 17 Apr 2001 21:31:00 GMT
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'm not comfortable with APR being a workaround for other problems.

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.


On Tue, Apr 17, 2001 at 10:14:41AM -0700, Doug MacEachern wrote:
> below is a complete patch to implement apr_dso_handle_close()
> the only cleanup that saved into apr_dso_handle_t was os390:
>  dso->failing_errno = errno;
> which is pointless since that value is returned by the function and
> nothing was checking it anyways.
> as you can see, the patch does not change any behavior, just exposes
> an api to do the native close.

Greg Stein, http://www.lyra.org/

View raw message