apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: Perl glue to APR
Date Sun, 23 May 2004 22:19:08 GMT
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.

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:

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.

Does that make sense and/or answer your question?

joe

Mime
View raw message