From: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 10:38 PM
> > > 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. If we were discussing operation, then I'd agree. We are talking about startup shutdown behavior, so I'm in favor of Greg's position here, stay with the interface we've defined for other such beasts. > > 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. We can all accept an os -> dso mechanism. But it's not APR's job to make 'other' mechanisms platform-independent, it's a complete wrapper to provide such services. Patching Perl is the way to go, but ITMT, if you can verify (through sizeof() or whatever) that we have an OS handle, then go for it. There will just need to be some mod_perl mechanism to assure that the perl module* == apr's dso os module*. > 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. We can all implement it, dreid and trawick are the folks on truly 'funky' platforms. The MPE guys might have some obscure issues, as well. If mod_perl marks those as incompatible, we should be good. > 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. What are you suggesting? We have a simple solution, APR_ENOTIMPL. If the platform can't handle a 'simple' native dso*, then it better return APR_ENOTIMPL. That isn't the same as testing that the os's dso mechanism we use is the same as perl's. It will have to be up to mod_perl to make that distinction. Bill
