apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: apr_dso_handle_close ?
Date Wed, 18 Apr 2001 15:37:33 GMT
On Tue, 17 Apr 2001 20:38:42 -0700 (PDT), rbb@covalent.net wrote:

>> > 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.

Well, I'm not all that keen on the concept but the patch looks like it will
work. I haven't actually tested it but it compiles, issuing a few warnings
as the native handle type is an unsigned long, not trivially convertable
to/from a void *

dso.c: In function `apr_dso_handle_close':
dso.c:64: warning: passing arg 1 of `DosFreeModule' makes integer from
pointer without a cast
dso.c: In function `dso_cleanup':
dso.c:76: warning: passing arg 1 of `apr_dso_handle_close' makes pointer
from integer without a cast

If we must have such a function it should take an apr_os_dso_t type arg,
not a void *.

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |

View raw message