httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <ra...@theoryx5.uwinnipeg.ca>
Subject Re: [mp2] decoupling APR from mod_perl
Date Mon, 19 Apr 2004 03:07:17 GMT
On Sat, 17 Apr 2004, Stas Bekman wrote:

> [xposting the modperl dev list]
>
> Joe Schaefer wrote:
>
> > Maybe a couple of us could get together on IRC sometime
> > this month and sort out what needs to be done to make it
> > happen.  I'd be willing to dedicate some time to the
> > effort it if I better understood what the relevant
> > issues are for mp2, and what course of action you guys
> > are taking/considering.
>
> I believe the whole issue is relatively trivial: We need
> to take all the functions that both mod_perl and APR libs
> rely on (that's the missing symbols you've got reported
> when you tried to load APR::Table w/o mod_perl.so being
> loaded and others used by other APR::* modules) and put
> them into a separate .[ch] files, so both APR.so and
> mod_perl.so can include. We already do that for
> modperl_constants.c, you can find a copy of
> src/modules/perl/modperl_constants.c as
> xs/ModPerl/Const/modperl_constants.c.  So we just need to
> copy these new *[ch] files into xs/APR/APR and arrange for
> build and inclusion of it in APR.so. And unless I've
> missed something it should just work. APR.pm and
> ModPerl/Const.pm already make sure that they won't attempt
> to load APR.so and Const.so if mod_perl.so is already
> loaded.

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::*).

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?

-- 
best regards,
randy

Mime
View raw message