httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] decoupling APR from mod_perl
Date Mon, 19 Apr 2004 03:36:23 GMT
Randy Kobes wrote:
>>I believe the whole issue is relatively trivial: We need
> As a first step, I looked through the APR::* modules, and
> came up with the following (entry-level) dependencies on
> Pool: modperl_interp_unselect (modperl_interp.c)
> Bucket: modperl_bucket_sv_create (modperl_bucket.c)
> OS: modperl_perl_sv_setref_uv (modperl_util.c)
> Socket,PerlIO: modperl_apr_strerror (modperl_util.c)
> Table: modperl_hash_tie, modperl_hash_tied_object
>   (modperl_util.c)
> URI: modperl_uri_new (modperl_util.c)
> However, this isn't the whole story, as some of these
> functions call other functions that are also in
> For example, modperl_bucket_sv_create needs
> modperl_bucket_sv_make, which in turn needs MP_TRACE_f, and
> so on ... Similarily, modperl_interp_unselect needs
> modperl_config_request_cleanup (in modperl_config.c) and
> modperl_tipool_putback_data (in modperl_tipool.c), and so on
> ... Only the functions in modperl_util.c seem to not depend
> strongly on other modperl_* functions (just on stuff in the
> Perl and Apache libraries).
> I started to put together a single file with all the needed
> symbols, but it's getting pretty large, and then starts to
> fracture the existing structure. How about, for those files
> that are needed, splitting them up into two files (eg,
> modperl_util.c and modperl_util_apr.c), with the *_apr.c
> file containing the functions needed by APR::*. Sometimes it
> may not be possible to split them up (eg, I think everything
> in modperl_bucket.c is needed by APR::*).

Not pretty. I haven't thought of these further dependencies :( Thanks for 
working on that, Randy!

> It also occurred to me though in trying to trace all the
> needed functions down - would it be easier to just treat
>, when using the APR::* modules, as a needed .so
> that has to be loaded, like an Apache libapr*.so or like
> Or is there a performance hit with having more
> functions than needed in an so?

I think it's not the best idea to depend on, since it may be not 
included in some distros which may want to distribute just the binary perl 
glue for APR (e.g. from APR site). Plus usually doesn't live under 
the perl tree, so it'll just require a way too much mess with configuration 
and unnecessary headaches to people who need to support the sw using APR:: 
(not talking about the users).

I suggest that as a first quick fix we simply link with all the same .o 
files is linked with, which immediatelly resolves the problem w/o 
requiring to mess up with the files. Later on we can think how to handle it 
more gracefully if at all.

Performance wise: will be a bigger file to read into the memory, but I 
don't think the loader reads the file, usually it mmaps it. Then the symbol 
resolution stage comes. On most platforms symbols resolution happens on 
demand, so it shouldn't be an issue. Indeed on those platforms that do 
RTLD_NOW all these irrelevant symbols will add to the loading time. But given 
that mod_cgi is pretty slow already, it probably won't make much difference. 
Though I haven't benchmarked that, so I could be totally wrong.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message