You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/04/16 05:43:03 UTC
Test build w/ Perl glue for CGI
I just put a build of current cvs at
http://cvs.apache.org/~joes/libapreq2-20040415.tar.gz
This bundle includes Randy's patch for
testing the CGI port of Apache::Request.
The strange thing is that the test script
at glue/perl/t/cgi-bin/test_cgi.pl seems
to work fine on Debian when I run it from
the command line, but the Apache::Test test
suite hangs after completing the first 7
tests successfully.
I have no clue what's going wrong, so I'd
appreciate it if other folks gave it a try
and report back on their experience.
Thanks.
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>That means that something is trying to load APR::Table w/o
>>mod_perl.so being loaded.
>
>
> And the solution for this is?
We should not load APR::Table unless mod_perl is running (e.g. s/use/require/
if $ENV{MOD_PERL}. I don't get this problem, since on linux symbols are
resolved on demand. Though I should be able to reproduce it with env var:
RTLD_NOW=1, which forces resolution at the startup.
So if you give me a tar to test with, I'll do that.
__________________________________________________________________
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
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> > [...]
> >
> >>As Joe suggested my idea won't work, since by including all other
> >>object files we will introduce new dependencies on ap_, so we need to
> >>figure out how to handle the Pool.so to get rid of the dependency on
> >> request_rec.
> > Right- it looks pretty tricky to me because of how mp2's ithread pools
> > interacts with the APR::Pool's cleanup callbacks. Because of this, I'm
> > tempted to suggest that the current APR::Pool implementation should be
> > renamed Apache::Pool, and a new (simpler) base class APR::Pool should be
> > constructed that doesn't rely on ap_*.
>
> Yes, that's quite possible. I didn't have a chance to look at it though.
I think it just boils down to removing this portion of mpxs_cleanup_run()
from APR__Pool.h:
#ifdef USE_ITHREADS
if (cdata->interp) {
/* this will decrement the interp refcnt until
* there are no more references, in which case
* the interpreter will be putback into the mip
*/
(void)modperl_interp_unselect(cdata->interp);
}
#endif
and making a new class, Apache::Pool, that is derived from APR::Pool.
You then need to install a few XSUBs for Apache::Pool that will run this
section as necessary.
Just a quick guess, but I don't believe it's too far off.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>As Joe suggested my idea won't work, since by including all other
>>object files we will introduce new dependencies on ap_, so we need to
>>figure out how to handle the Pool.so to get rid of the dependency on
>>request_rec.
>
>
> Right- it looks pretty tricky to me because of how mp2's
> ithread pools interacts with the APR::Pool's cleanup callbacks.
> Because of this, I'm tempted to suggest that the current APR::Pool
> implementation should be renamed Apache::Pool, and a new (simpler)
> base class APR::Pool should be constructed that doesn't rely on ap_*.
Yes, that's quite possible. I didn't have a chance to look at it though.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> As Joe suggested my idea won't work, since by including all other
> object files we will introduce new dependencies on ap_, so we need to
> figure out how to handle the Pool.so to get rid of the dependency on
> request_rec.
Right- it looks pretty tricky to me because of how mp2's
ithread pools interacts with the APR::Pool's cleanup callbacks.
Because of this, I'm tempted to suggest that the current APR::Pool
implementation should be renamed Apache::Pool, and a new (simpler)
base class APR::Pool should be constructed that doesn't rely on ap_*.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 21 Apr 2004, Joe Schaefer wrote:
>
>
>>Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>>
>>
>>>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)
>>
>>This one looks to be a PITA because of the (eventual)
>>request_rec dependence.
>>
>>
>>>Bucket: modperl_bucket_sv_create (modperl_bucket.c)
>>
>>Simple fix- add
>>
>> #include "modperl_bucket.c"
>>
>>to APR__Bucket.h.
>>
>>[...]
>>
>>
>>>Table: modperl_hash_tie, modperl_hash_tied_object
>>> (modperl_util.c)
>>
>>Simple fix: copy those two functions from modperl_util.c
>>right into APR__Table.h.
>>
>>The above fixes produce the following from `make`:
>>
>> % for i in Bucket Brigade Pool Table; do echo "APR/$i/$i.so:";
>> > nm --dynamic blib/arch/Apache2/auto/APR/$i/$i.so | grep modperl;
>> > done
>> APR/Bucket/Bucket.so:
>> 0000000000001b90 T modperl_bucket_sv_create
>> APR/Brigade/Brigade.so:
>> APR/Pool/Pool.so:
>> U modperl_interp_unselect
>> APR/Table/Table.so:
>> 0000000000004cd0 T modperl_hash_tie
>> 0000000000002590 T modperl_hash_tied_object
>>
>>so IMO if we can figure out what to do about APR::Pool, the
>>other changes needed (for apreq2's Apache::Request) will be
>>straightforward.
>
>
> For this, could we, like Stas suggested, just including
> at link time all the object files that make up mod_perl.so,
> instead of against mod_perl.so?
As Joe suggested my idea won't work, since by including all other object files
we will introduce new dependencies on ap_, so we need to figure out how to
handle the Pool.so to get rid of the dependency on request_rec.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 21 Apr 2004, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> > 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)
>
> This one looks to be a PITA because of the (eventual)
> request_rec dependence.
>
> > Bucket: modperl_bucket_sv_create (modperl_bucket.c)
>
> Simple fix- add
>
> #include "modperl_bucket.c"
>
> to APR__Bucket.h.
>
> [...]
>
> > Table: modperl_hash_tie, modperl_hash_tied_object
> > (modperl_util.c)
>
> Simple fix: copy those two functions from modperl_util.c
> right into APR__Table.h.
>
> The above fixes produce the following from `make`:
>
> % for i in Bucket Brigade Pool Table; do echo "APR/$i/$i.so:";
> > nm --dynamic blib/arch/Apache2/auto/APR/$i/$i.so | grep modperl;
> > done
> APR/Bucket/Bucket.so:
> 0000000000001b90 T modperl_bucket_sv_create
> APR/Brigade/Brigade.so:
> APR/Pool/Pool.so:
> U modperl_interp_unselect
> APR/Table/Table.so:
> 0000000000004cd0 T modperl_hash_tie
> 0000000000002590 T modperl_hash_tied_object
>
> so IMO if we can figure out what to do about APR::Pool, the
> other changes needed (for apreq2's Apache::Request) will be
> straightforward.
For this, could we, like Stas suggested, just including
at link time all the object files that make up mod_perl.so,
instead of against mod_perl.so?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> 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)
This one looks to be a PITA because of the (eventual)
request_rec dependence.
> Bucket: modperl_bucket_sv_create (modperl_bucket.c)
Simple fix- add
#include "modperl_bucket.c"
to APR__Bucket.h.
[...]
> Table: modperl_hash_tie, modperl_hash_tied_object
> (modperl_util.c)
Simple fix: copy those two functions from modperl_util.c
right into APR__Table.h.
The above fixes produce the following from `make`:
% for i in Bucket Brigade Pool Table; do echo "APR/$i/$i.so:";
> nm --dynamic blib/arch/Apache2/auto/APR/$i/$i.so | grep modperl;
> done
APR/Bucket/Bucket.so:
0000000000001b90 T modperl_bucket_sv_create
APR/Brigade/Brigade.so:
APR/Pool/Pool.so:
U modperl_interp_unselect
APR/Table/Table.so:
0000000000004cd0 T modperl_hash_tie
0000000000002590 T modperl_hash_tied_object
so IMO if we can figure out what to do about APR::Pool, the
other changes needed (for apreq2's Apache::Request) will be
straightforward.
> 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?
That doesn't really help because of mod_perl.so's ap_*
dependence. There's no libhttpd on *nix that will resolve
the missing ap_* symbols from mod_perl.so.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
[mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
[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.
Notice that modperl-2.0/t/apr-ext files exercise the APR-w/o-mod_perl already
(at the moment it is only possible for some APR:: libs).
So if there is an urgency to resolve this issue now, we can do that.
Please notice that there are known problems with linking APR.so on some
platforms, I believe only Solaris was reported so far. Since I don't use
Solaris and nobody has volunteered help so far it's unresolved and t/apr-ext
tests fail on that platform.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
[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.
Notice that modperl-2.0/t/apr-ext files exercise the APR-w/o-mod_perl already
(at the moment it is only possible for some APR:: libs).
So if there is an urgency to resolve this issue now, we can do that.
Please notice that there are known problems with linking APR.so on some
platforms, I believe only Solaris was reported so far. Since I don't use
Solaris and nobody has volunteered help so far it's unresolved and t/apr-ext
tests fail on that platform.
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Don't waste your time, Randy. Once APR is decoupled from mp2 it'll
> just work on its own.
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'm on the dev@perl list via gmane, in case Stas, Geoff or somebody
else wants to rekindle this fire over there.
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 17 Apr 2004, Joe Schaefer wrote:
>
>
>>Stas Bekman <st...@stason.org> writes:
>>
>>
>>>Can you explain why are you trying to run mod_perl libraries w/o loading
>>>mod_perl.so in first place? What is this test about? Is it about
>>>Apache::Request working w/o mod_perl? In which case it won't work,
>>>until we fix APR::Table not to rely on mod_perl.so (which is doable
>>>and planned). Is that what you are after?
>>
>>Bingo. The 2.03-dev release is supposed to add CGI to the supported
>>environments for Apache::Request. If APR::Table (and APR::Brigade, btw)
>>is going to be "divorced" from mod_perl.so soonish, we might be able to
>>go forward with it. Otherwise I think we'll need to put it off until
>>2.04-dev (I'd really like 2.04 to be our final dev release, with 2.05
>>being the supported, stable release).
>
>
> Decoupling APR:* from mod_perl.so would be the goal; what
> I wanted with these perl cgi tests is just to see in
> principle if they would work. So I took the view that
> mod_perl.so was (on Win32) just a dll that provided some
> needed symbols, and made that available to the perl
> cgi script. At one point this also worked on linux,
> I thought with just setting LD_LIBRARY_PATH, but I
> guess there must have been more - I'll look at this next
> week (I'm away for a few days).
Don't waste your time, Randy. Once APR is decoupled from mp2 it'll just work
on its own.
--
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 17 Apr 2004, Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> > Can you explain why are you trying to run mod_perl libraries w/o loading
> > mod_perl.so in first place? What is this test about? Is it about
> > Apache::Request working w/o mod_perl? In which case it won't work,
> > until we fix APR::Table not to rely on mod_perl.so (which is doable
> > and planned). Is that what you are after?
>
> Bingo. The 2.03-dev release is supposed to add CGI to the supported
> environments for Apache::Request. If APR::Table (and APR::Brigade, btw)
> is going to be "divorced" from mod_perl.so soonish, we might be able to
> go forward with it. Otherwise I think we'll need to put it off until
> 2.04-dev (I'd really like 2.04 to be our final dev release, with 2.05
> being the supported, stable release).
Decoupling APR:* from mod_perl.so would be the goal; what
I wanted with these perl cgi tests is just to see in
principle if they would work. So I took the view that
mod_perl.so was (on Win32) just a dll that provided some
needed symbols, and made that available to the perl
cgi script. At one point this also worked on linux,
I thought with just setting LD_LIBRARY_PATH, but I
guess there must have been more - I'll look at this next
week (I'm away for a few days).
--
best regards,
randy
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Can you explain why are you trying to run mod_perl libraries w/o loading
>>mod_perl.so in first place? What is this test about? Is it about
>>Apache::Request working w/o mod_perl? In which case it won't work,
>>until we fix APR::Table not to rely on mod_perl.so (which is doable
>>and planned). Is that what you are after?
>
>
> Bingo. The 2.03-dev release is supposed to add CGI to the supported
> environments for Apache::Request. If APR::Table (and APR::Brigade, btw)
> is going to be "divorced" from mod_perl.so soonish, we might be able to
> go forward with it. Otherwise I think we'll need to put it off until
> 2.04-dev.
Please pull it off until 2.04-dev, I don't want to start to work on yet
another thing before I finish a few other things that I've started ages ago.
Unless of course somebody beats me to it. Of course nudge me to do so if I
don't get to do it in a few weeks.
> (I'd really like 2.04 to be our final dev release, with 2.05
> being the supported, stable release).
Nice!
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Can you explain why are you trying to run mod_perl libraries w/o loading
> mod_perl.so in first place? What is this test about? Is it about
> Apache::Request working w/o mod_perl? In which case it won't work,
> until we fix APR::Table not to rely on mod_perl.so (which is doable
> and planned). Is that what you are after?
Bingo. The 2.03-dev release is supposed to add CGI to the supported
environments for Apache::Request. If APR::Table (and APR::Brigade, btw)
is going to be "divorced" from mod_perl.so soonish, we might be able to
go forward with it. Otherwise I think we'll need to put it off until
2.04-dev (I'd really like 2.04 to be our final dev release, with 2.05
being the supported, stable release).
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Can you explain why are you trying to run mod_perl libraries w/o loading
mod_perl.so in first place? What is this test about? Is it about
Apache::Request working w/o mod_perl? In which case it won't work, until we
fix APR::Table not to rely on mod_perl.so (which is doable and planned). Is
that what you are after?
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> On Fri, 16 Apr 2004, Joe Schaefer wrote:
>
> > Stas Bekman <st...@stason.org> writes:
> >
> > [...]
> >
> > > That means that something is trying to load APR::Table w/o
> > > mod_perl.so being loaded.
> >
> > And the solution for this is?
>
> On Win32 I just put mod_perl.so in the cgi-bin directory
> where the script is - this worked as Win32 checks the
> current directory for needed dlls.
Neat.
> On linux, if I remember correctly, I set LD_LIBRARY_PATH to include
> the Apache2 modules/ directory (I know this isn't great, but it was
> just for a proof of concept).
Can you please elaborate ? I added
SetEnv LD_LIBRARY_PATH "/path/to/apache2/modules"
to the /cgi-bin/ directives in t/conf/extra.conf, but it didn't fix
anything. Also were it possible, there's a even bigger problem with loading
mod_perl.so- many of _its_ symbols are unresolved because they're part
of the httpd executable (all the ap_* calls). DynaLoader::dl_load_file
does not seem to like this (it won't load mod_perl.so on linux).
> By the way, on Win32, all the perl cgi tests were successful
> if one used the smaller keys (as described in the comments
> in the cgi script). There seemed to be some sharp point in
> the sizes involved at which the tests hang.
If you run test 8 directly from the command line, the script works fine.
Also when I changed the script's apreq_log sub to a noop :
sub apreq_log {
return;
}
everything but the cookie tests passed, even when using the larger
keys. Quite strange that IO (or lack thereof) on stderr influences the
outcome.
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 16 Apr 2004, Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
> > That means that something is trying to load APR::Table w/o
> > mod_perl.so being loaded.
>
> And the solution for this is?
On Win32 I just put mod_perl.so in the cgi-bin directory
where the script is - this worked as Win32 checks the
current directory for needed dlls. On linux, if I remember
correctly, I set LD_LIBRARY_PATH to include the Apache2
modules/ directory (I know this isn't great, but it was just
for a proof of concept).
By the way, on Win32, all the perl cgi tests were successful
if one used the smaller keys (as described in the comments
in the cgi script). There seemed to be some sharp point in
the sizes involved at which the tests hang.
--
best regards,
randy
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> That means that something is trying to load APR::Table w/o
> mod_perl.so being loaded.
And the solution for this is?
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Geoffrey Young <ge...@modperlcookbook.org> writes:
>>>
>>>
>>>>Joe Schaefer wrote:
>>>
>>>[...]
>>>
>>>
>>>>>The strange thing is that the test script
>>>>>at glue/perl/t/cgi-bin/test_cgi.pl seems
>>>>>to work fine on Debian when I run it from the command line, but the
>>>>>Apache::Test test suite hangs after completing the first 7 tests
>>>>>successfully.
>>>>
>>>>I see the same thing, no ideas though.
>>>>
>>>>btw, the test_cgi.pl script has a hard-coded perl for your system in
>>>>it. I'd suggest using t_write_perl_script() for the generation of all
>>>>cgi scripts (not just this one). patch for this one only attached.
>>>
>>>Thanks! A patched package is available at
>>> http://cvs.apache.org/~joes/libapreq2-20040416.tar.gz
>>>Folks, please try this one. If we can't figure out why
>>>the cgi tests are hanging, maybe we should just skip
>>>tests 8-31 for now and commit the test script (glue/perl/t/cgi.t)
>>>to cvs.
>>
>>Give it some time to timeout, it's not 8-31 that fail. It fails on 8th (15
>>keys), but succeeds on 9th (26 keys) and next time it hangs on 14th, etc.
>>
>>The error is:
>>
>>[Fri Apr 16 12:40:24 2004] [error] [client 127.0.0.1] Premature end of script
>>headers: test_cgi.pl
>>
>>Sounds like a buggy code. I didn't dig into it.
>
>
> That's hard to believe, since it's the exact same test script from env/t.
> To eliminate the timeouts I commented out all the apreq_log calls in the
> generated cgi script (whatever bug that now avoids isn't a problem with
> Apache::Request). It runs to completion, but fails the final cookie
> tests 27-31 because some modperl symbols are missing from APR::Table.
> The error log for the failed cookie tests now yields
>
> relocation error: /home/joe/lib/perl5/site_perl/5.9.0/x86_64-linux-thread-multi-ld/Apache2/auto/APR/Table/Table.so: undefined symbol: modperl_hash_tied_object
That means that something is trying to load APR::Table w/o mod_perl.so being
loaded.
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 16 Apr 2004, Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> > Joe Schaefer wrote:
> > > Geoffrey Young <ge...@modperlcookbook.org> writes:
> > >
> > >>Joe Schaefer wrote:
> > > [...]
> > >
> > >>>The strange thing is that the test script
> > >>>at glue/perl/t/cgi-bin/test_cgi.pl seems
> > >>> to work fine on Debian when I run it from the
> > >>> command line, but the Apache::Test test suite hangs
> > >>> after completing the first 7 tests successfully.
> > >>
> > >>I see the same thing, no ideas though.
> > >>
> > >>btw, the test_cgi.pl script has a hard-coded perl for your system in
> > >>it. I'd suggest using t_write_perl_script() for the generation of all
> > >>cgi scripts (not just this one). patch for this one only attached.
> > > Thanks! A patched package is available at
> > > http://cvs.apache.org/~joes/libapreq2-20040416.tar.gz
> > > Folks, please try this one. If we can't figure out why
> > > the cgi tests are hanging, maybe we should just skip
> > > tests 8-31 for now and commit the test script (glue/perl/t/cgi.t)
> > > to cvs.
> >
> > Give it some time to timeout, it's not 8-31 that fail.
> > It fails on 8th (15 keys), but succeeds on 9th (26 keys)
> > and next time it hangs on 14th, etc.
> >
> > The error is:
> >
> > [Fri Apr 16 12:40:24 2004] [error] [client 127.0.0.1]
> > Premature end of script headers: test_cgi.pl
> >
> > Sounds like a buggy code. I didn't dig into it.
>
> That's hard to believe, since it's the exact same test script from env/t.
> To eliminate the timeouts I commented out all the apreq_log calls in the
> generated cgi script (whatever bug that now avoids isn't a problem with
> Apache::Request). It runs to completion ...
[ ... ]
I'm not sure why, but I think this problem comes when trying
to print out large values to STDERR - if one comments out
just the apreq_log() call that prints out the value of the
parameter, but leave the others, then the script doesn't
timeout.
--
best regards,
randy
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Geoffrey Young <ge...@modperlcookbook.org> writes:
> >
> >>Joe Schaefer wrote:
> > [...]
> >
> >>>The strange thing is that the test script
> >>>at glue/perl/t/cgi-bin/test_cgi.pl seems
> >>> to work fine on Debian when I run it from the command line, but the
> >>> Apache::Test test suite hangs after completing the first 7 tests
> >>> successfully.
> >>
> >>I see the same thing, no ideas though.
> >>
> >>btw, the test_cgi.pl script has a hard-coded perl for your system in
> >>it. I'd suggest using t_write_perl_script() for the generation of all
> >>cgi scripts (not just this one). patch for this one only attached.
> > Thanks! A patched package is available at
> > http://cvs.apache.org/~joes/libapreq2-20040416.tar.gz
> > Folks, please try this one. If we can't figure out why
> > the cgi tests are hanging, maybe we should just skip
> > tests 8-31 for now and commit the test script (glue/perl/t/cgi.t)
> > to cvs.
>
> Give it some time to timeout, it's not 8-31 that fail. It fails on 8th (15
> keys), but succeeds on 9th (26 keys) and next time it hangs on 14th, etc.
>
> The error is:
>
> [Fri Apr 16 12:40:24 2004] [error] [client 127.0.0.1] Premature end of script
> headers: test_cgi.pl
>
> Sounds like a buggy code. I didn't dig into it.
That's hard to believe, since it's the exact same test script from env/t.
To eliminate the timeouts I commented out all the apreq_log calls in the
generated cgi script (whatever bug that now avoids isn't a problem with
Apache::Request). It runs to completion, but fails the final cookie
tests 27-31 because some modperl symbols are missing from APR::Table.
The error log for the failed cookie tests now yields
relocation error: /home/joe/lib/perl5/site_perl/5.9.0/x86_64-linux-thread-multi-ld/Apache2/auto/APR/Table/Table.so: undefined symbol: modperl_hash_tied_object
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
>>Joe Schaefer wrote:
>
>
> [...]
>
>
>>>The strange thing is that the test script
>>>at glue/perl/t/cgi-bin/test_cgi.pl seems
>>>to work fine on Debian when I run it from
>>>the command line, but the Apache::Test test
>>>suite hangs after completing the first 7
>>>tests successfully.
>>
>>I see the same thing, no ideas though.
>>
>>btw, the test_cgi.pl script has a hard-coded perl for your system in
>>it. I'd suggest using t_write_perl_script() for the generation of all
>>cgi scripts (not just this one). patch for this one only attached.
>
>
> Thanks! A patched package is available at
>
> http://cvs.apache.org/~joes/libapreq2-20040416.tar.gz
>
> Folks, please try this one. If we can't figure out why
> the cgi tests are hanging, maybe we should just skip
> tests 8-31 for now and commit the test script (glue/perl/t/cgi.t)
> to cvs.
Give it some time to timeout, it's not 8-31 that fail. It fails on 8th (15
keys), but succeeds on 9th (26 keys) and next time it hangs on 14th, etc.
The error is:
[Fri Apr 16 12:40:24 2004] [error] [client 127.0.0.1] Premature end of script
headers: test_cgi.pl
Sounds like a buggy code. I didn't dig into it.
__________________________________________________________________
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
Re: Test build w/ Perl glue for CGI
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> Joe Schaefer wrote:
[...]
> > The strange thing is that the test script
> > at glue/perl/t/cgi-bin/test_cgi.pl seems
> > to work fine on Debian when I run it from
> > the command line, but the Apache::Test test
> > suite hangs after completing the first 7
> > tests successfully.
>
> I see the same thing, no ideas though.
>
> btw, the test_cgi.pl script has a hard-coded perl for your system in
> it. I'd suggest using t_write_perl_script() for the generation of all
> cgi scripts (not just this one). patch for this one only attached.
Thanks! A patched package is available at
http://cvs.apache.org/~joes/libapreq2-20040416.tar.gz
Folks, please try this one. If we can't figure out why
the cgi tests are hanging, maybe we should just skip
tests 8-31 for now and commit the test script (glue/perl/t/cgi.t)
to cvs.
--
Joe Schaefer
Re: Test build w/ Perl glue for CGI
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> I just put a build of current cvs at
>
> http://cvs.apache.org/~joes/libapreq2-20040415.tar.gz
>
> This bundle includes Randy's patch for
> testing the CGI port of Apache::Request.
> The strange thing is that the test script
> at glue/perl/t/cgi-bin/test_cgi.pl seems
> to work fine on Debian when I run it from
> the command line, but the Apache::Test test
> suite hangs after completing the first 7
> tests successfully.
I see the same thing, no ideas though.
btw, the test_cgi.pl script has a hard-coded perl for your system in it.
I'd suggest using t_write_perl_script() for the generation of all cgi
scripts (not just this one). patch for this one only attached.
--Geoff