On Thu, 24 Jun 2004, Stas Bekman wrote:
[ ... ]
But which of the apr-ext tests happen to select interpreters at all? Can you find out why did you need that workaround. It's quite possible that your patch is the right thing to do, but I made it a no-op since I didn't see why would you want to unselect it at all.
Actually, without the workaround, the apr-ext tests all pass for me, when run by themselves. The problem arose in the other tests - running 'nmake test' first encounters a problem with t/apache/discard_rbody hanging. But others hang as well when the order of the tests is changed.
I suppose the issue comes from loading APR.so and mod_perl.so at the same time and having the wrong symbol kicking in. It should have picked mod_perl.so's modperl_interp_unselect, not APR.so's one.
I think that's what's happening - it's picking up APR.so's modperl_interp_unselect everywhere for all APR/APR::* modules. This is because I did away with linking to mod_perl.so for all APR::* modules, including APR itself - if not, if mod_perl.so provides any symbols at all at link time, using APR and/or APR::* will demand that mod_perl.so be available.
What happens if in the future we will need to provide different functionality for the same function one residing in APR.so and the other in mod_perl.so? There is no way you can avoid linking mod_perl.so against APR.so?
If you can't control that, the right solution is to move modperl_interp_unselect into the common area, instead of duplicating it. Notice that I added that workaround before we did the split, so it's probably the right thing to do in any case.
Just so I understand correctly, does that mean to remove modperl_interp_unselect from both xs/APR/APR/APR.xs and src/modules/perl/modperl_interp.c, and instead put in =================================================================== apr_status_t modperl_interp_unselect(void *data) { #ifdef USE_ITHREADS modperl_interp_t *interp = (modperl_interp_t *)data; if (interp->refcnt != 0) { --interp->refcnt; } #endif /* USE_ITHREADS */ return APR_SUCCESS; } #endif /* modperl_interp_unselect */ =================================================================== into something like src/modules/perl/modperl_common_util.c? And since this needs modperl_interp_t, move the declaration of this from src/modules/perl/modperl_types.h into src/modules/perl/modperl_common_types.h?
doh! you are right, there aren't the same. if you copy modperl_interp_unselect from modperl_interp.c you will create a dependency on mod_perl.so.
I think the proper solution might be to rework the code that uses unselect to call that function only if it figures out it's running inside Apache? I haven't looked at how complex that would be.
I noticed that modperl_interp_unselect is also used within src/modules/perl/mod_perl.c - if the above is correct, will that change affect anything there?
why should the move affect anything? it'll be still available as before.
Another concern (unrelated to this issue) is that we are now messing the mapping of API groups within the files they are implemented in. I suppose it needs to go into modperl_common_interp.[ch] to keep in sync.
Also may be we should replace /^modperl_common/ with some shorter name. Ideally that prefix would be /^apr_/, but since quite a few of those things aren't really coming from APR that choice may be confusing.
We don't have to shuffle the files/names now, besides layout out a plan and finish the split first and have things working.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
