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 mod_perl.so:
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 mod_perl.so. 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 mod_perl.so, when using the APR::* modules, as a needed .so that has to be loaded, like an Apache libapr*.so or like libapreq2.so? 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 mod_perl.so, 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 mod_perl.so 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 APR.so with all the same .o files mod_perl.so 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: APR.so 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 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]
