apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Perl glue to APR
Date Mon, 24 May 2004 18:03:17 GMT
Joe Orton wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message