On Thu, May 20, 2004 at 03:16:28PM -0500, Randy Kobes wrote:
How it's being planned to divorce APR::* from mod_perl.so is to include the sources for the relevant symbols currently in mod_perl.so in building an APR.so, and then load APR.so when using an APR::* module. However, this leads to the possibility of someone loading both mod_perl.so and APR.so, which would contain identical symbols. The question is then if this would be a problem in general, or perhaps on specific platforms?
AFAIK it wouldn't be a problem on any Unix using dlopen(), I'm not sure about AIX though, it's not very Unixy in this respect. Dunno about non-Unixes either.
Yeah, AIX is like windows. Any AIX experts here?
Because if the way dlopen() is used in both httpd and Perl/DynaLoader (both passing the flags RTLD_GLOBAL|RTLD_NOW), you do get behaviour which is consistent with the ordering of the libraries passed to cc, and so you have to be careful, as I understand it:
On most unices perl doesn't pass RTLD_NOW. I know it does on MacOSX.
There is a global symbol table for each process; in dlopen, any newly loaded .so files will have their undefined symbols resolved using that table. Any remaining newly defined symbols in the .so will then be added to that global symbol table.
So if you have both mod_perl.so and some APR/Foo.so defining a global function 'foo', when mod_perl/Perl/Dynaloader loads the APR/Foo.so, all it's references to the function 'foo' will use the foo already loaded in mod_perl.so. Hence, obviously, you must make sure that any duplicate functions between the two objects really are the same function. Use of static data must be done carefully from such functions.
Good point. Though we should try hard to avoid using any static data at all in the apr land, because of the threaded environment.
Does that make sense and/or answer your question?
I suppose we could try to do that and if that doesn't work on certain platforms, either provide a separate solution for those platforms or revert to where things are now.
That's great. So pretty soon you will be able to write your favorite APR code in perl w/o needing to have Apache/mod_perl around.
-- __________________________________________________________________ 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
