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 Stas Bekman <st...@stason.org> on 2003/10/30 07:47:45 UTC
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
joes@apache.org wrote:
> joes 2003/10/29 20:45:52
>
> Modified: build xsbuilder.pl
> Log:
> Improve the perl glue's environment check by following the recipe in CGI.pm
>
> Revision Changes Path
> 1.18 +14 -2 httpd-apreq-2/build/xsbuilder.pl
>
> Index: xsbuilder.pl
> ===================================================================
> RCS file: /home/cvs/httpd-apreq-2/build/xsbuilder.pl,v
> retrieving revision 1.17
> retrieving revision 1.18
> diff -u -r1.17 -r1.18
> --- xsbuilder.pl 30 Oct 2003 01:22:00 -0000 1.17
> +++ xsbuilder.pl 30 Oct 2003 04:45:52 -0000 1.18
> @@ -237,8 +237,20 @@
> # The modperl package isn't necessarily loaded, but Apache2
> # is. Perhaps Apache2 should always include a VERSION?
No, it shouldn't. If it does people will start using it in their code
to check for version which won't work when mp3 comes out.
> -die __PACKAGE__ . ": httpd must load mod_apreq.so first"
> - if __PACKAGE__->env ne "Apache::RequestRec";
> +if (\$ENV{MOD_PERL}) {
> + require mod_perl;
> + if (\$mod_perl::VERSION > 1.99) {
> + die __PACKAGE__ . ": httpd must load mod_apreq.so first"
> + if __PACKAGE__->env ne "Apache::RequestRec";
> + }
> + elsif (\$mod_perl::VERSION > 1.24) {
> + die __PACKAGE__ . ": httpd must load mod_apreq1.so first"
> + if __PACKAGE__->env ne "Apache";
A::R 2 supports mp1?
__________________________________________________________________
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: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>- make an Apreq::Base, consisting of a Base.xs that just
>>made available apr_initialize() and apr_terminate2().
>>- make an Apreq::Request which loads Apreq::Base and has
>>a new() method to create an Apreq::Request object by
>> - calling apr_initialize()
>> - creating a $p = APR::Pool->new()
>> - creating a $req = Apache::Request->new($p, @_)
>>- make an Apreq::Cookie which similarly passes a $p pool
>>in as the $env within Apache/Cookie.pm.
>>- I'm not sure about this, but I also made a DESTROY sub
>>which calls apr_terminate2().
>
>
> initialize/terminate are per-process events, so calling them
> from the object ctor/dtor is probably a mistake. IMO those calls
> probably belong inside BEGIN and END blocks within APR.pm.
> If that were so, Base.xs would be unnecessary, right?
s/BEGIN/BOOT/ and APR.pm does that already:
xs/APR/APR/APR.xs:
MODULE = APR PACKAGE = APR
PROTOTYPES: disable
BOOT:
file = file; /* -Wall */
APR_initialize();
extra_apr_init();
void
END()
CODE:
APR_terminate();
__________________________________________________________________
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: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> On Fri, 31 Oct 2003, Joe Schaefer wrote:
[...]
> In any event, I did this more as a proof of concept, in that
> it shows things seem workable in principle within a cgi
> environment, and even from within the current state of mp2
> where mod_perl.so must be used (as an so providing some
> symbols). Is the perl glue something that you think should
> be persued to more detail now, or should we wait until the
> necessary symbols needed from mod_perl.so are moved
> elsewhere?
Actually I'm trying to decide what should go in the 2.01-dev
release, which I'd like to start ASAP (see the new RELEASE
file in cvs). I think any decisions regarding the CGI perl glue can
wait until 2.02-dev starts, so I'd say keep experimenting with it.
--
Joe Schaefer
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 31 Oct 2003, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> [...]
>
> > Until things are arranged so that all the needed APR::* can
> > be used outside of mp2, I've been looking at the perl glue
> > in a CGI context, just to see what's involved. This entails
> > having available mod_perl.so as an so/dll. Although this may
> > not be the best model, I tried the following, just to see if
> > it works:
>
> Cool.
>
> > - make an Apreq::Base, consisting of a Base.xs that just
> > made available apr_initialize() and apr_terminate2().
> > - make an Apreq::Request which loads Apreq::Base and has
> > a new() method to create an Apreq::Request object by
> > - calling apr_initialize()
> > - creating a $p = APR::Pool->new()
> > - creating a $req = Apache::Request->new($p, @_)
> > - make an Apreq::Cookie which similarly passes a $p pool
> > in as the $env within Apache/Cookie.pm.
> > - I'm not sure about this, but I also made a DESTROY sub
> > which calls apr_terminate2().
>
> initialize/terminate are per-process events, so calling them
> from the object ctor/dtor is probably a mistake. IMO those calls
> probably belong inside BEGIN and END blocks within APR.pm.
> If that were so, Base.xs would be unnecessary, right?
That does seem right, and as Stas noted, APR.xs does that
already. But when I tried the apreq stuff from within a CGI
environment just by using APR and APR::Pool, things crashed,
which was cured by putting in the apr_initialize() call from
Apreq::Base (I'm not sure if this problem is at all related
to the disabling of some of the mp2 apr-ext/ tests?). I'll
look at this in more detail, though - you're right that in
principle an Apreq::Base like this shouldn't be needed, or
even done.
In any event, I did this more as a proof of concept, in that
it shows things seem workable in principle within a cgi
environment, and even from within the current state of mp2
where mod_perl.so must be used (as an so providing some
symbols). Is the perl glue something that you think should
be persued to more detail now, or should we wait until the
necessary symbols needed from mod_perl.so are moved
elsewhere?
--
best regards,
randy
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> I know this can wait until the next development cycle, but
> just to record this ... For some reason just using APR.pm to
> call apr_initialize/apr_terminate (through APR.xs) doesn't
> seem to work for the CGI environment, and yet putting the
> same code in an Apreq/Base.xs:
> ================================================================
> BOOT:
> apr_initialize();
>
> void
> END()
>
> CODE:
> apr_terminate2();
> ================================================================
> does work. I'll look into this some more ...
If you copy this from APR.xs, make sure to copy the whole BOOT. apr_initialize
has a bug in its init, which is worked around in APR.xs.
__________________________________________________________________
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: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 31 Oct 2003, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> [...]
>
> > Until things are arranged so that all the needed APR::* can
> > be used outside of mp2, I've been looking at the perl glue
> > in a CGI context, just to see what's involved. This entails
> > having available mod_perl.so as an so/dll. Although this may
> > not be the best model, I tried the following, just to see if
> > it works:
>
> Cool.
>
> > - make an Apreq::Base, consisting of a Base.xs that just
> > made available apr_initialize() and apr_terminate2().
> > - make an Apreq::Request which loads Apreq::Base and has
> > a new() method to create an Apreq::Request object by
> > - calling apr_initialize()
> > - creating a $p = APR::Pool->new()
> > - creating a $req = Apache::Request->new($p, @_)
> > - make an Apreq::Cookie which similarly passes a $p pool
> > in as the $env within Apache/Cookie.pm.
> > - I'm not sure about this, but I also made a DESTROY sub
> > which calls apr_terminate2().
>
> initialize/terminate are per-process events, so calling them
> from the object ctor/dtor is probably a mistake. IMO those calls
> probably belong inside BEGIN and END blocks within APR.pm.
> If that were so, Base.xs would be unnecessary, right?
I know this can wait until the next development cycle, but
just to record this ... For some reason just using APR.pm to
call apr_initialize/apr_terminate (through APR.xs) doesn't
seem to work for the CGI environment, and yet putting the
same code in an Apreq/Base.xs:
================================================================
BOOT:
apr_initialize();
void
END()
CODE:
apr_terminate2();
================================================================
does work. I'll look into this some more ...
--
best regards,
randy
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> Until things are arranged so that all the needed APR::* can
> be used outside of mp2, I've been looking at the perl glue
> in a CGI context, just to see what's involved. This entails
> having available mod_perl.so as an so/dll. Although this may
> not be the best model, I tried the following, just to see if
> it works:
Cool.
> - make an Apreq::Base, consisting of a Base.xs that just
> made available apr_initialize() and apr_terminate2().
> - make an Apreq::Request which loads Apreq::Base and has
> a new() method to create an Apreq::Request object by
> - calling apr_initialize()
> - creating a $p = APR::Pool->new()
> - creating a $req = Apache::Request->new($p, @_)
> - make an Apreq::Cookie which similarly passes a $p pool
> in as the $env within Apache/Cookie.pm.
> - I'm not sure about this, but I also made a DESTROY sub
> which calls apr_terminate2().
initialize/terminate are per-process events, so calling them
from the object ctor/dtor is probably a mistake. IMO those calls
probably belong inside BEGIN and END blocks within APR.pm.
If that were so, Base.xs would be unnecessary, right?
--
Joe Schaefer
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 30 Oct 2003, Joe Schaefer wrote:
[ ... ]
> However, I'd really like to see the perl glue ported to
> CGI first, since we've already got that working in C.
> How much of the APR:: stuff (pools, brigades, etc.) in mp2
> will run outside of mp2?
Until things are arranged so that all the needed APR::* can
be used outside of mp2, I've been looking at the perl glue
in a CGI context, just to see what's involved. This entails
having available mod_perl.so as an so/dll. Although this may
not be the best model, I tried the following, just to see if
it works:
- make an Apreq::Base, consisting of a Base.xs that just
made available apr_initialize() and apr_terminate2().
- make an Apreq::Request which loads Apreq::Base and has
a new() method to create an Apreq::Request object by
- calling apr_initialize()
- creating a $p = APR::Pool->new()
- creating a $req = Apache::Request->new($p, @_)
- make an Apreq::Cookie which similarly passes a $p pool
in as the $env within Apache/Cookie.pm.
- I'm not sure about this, but I also made a DESTROY sub
which calls apr_terminate2().
Testing this with the env/t/cgi.t tests against a perl
version of env/test_cgi.c has all tests passing, except for
a problem with the largest POST tests. But this very well
may be due to something I've missed in setting things up.
--
best regards,
randy
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>
>
> [...]
>
>
>>>>A::R 2 supports mp1?
>>>
>>>In a manner of speaking, yes. Firstly, mod_apreq1.c needs to be
>>>born, and secondly, the perl glue needs to be amended to subclass
>>>from "Apache". Until both of those things happen, our perl glue must
>>>fail to load for mp1. Of course, the error message could recommend
>>>using libapreq-1.X here, but hey, why be pessimistic about it?
>>
>>That's very cool! So in the back of your mind you have an evil plan to
>>drop the current libapreq-1 and maintain just one source for both
>>Apache generation? ;)
>
>
> Potentially, if there's sufficient interest. However, I'd really like
> to see the perl glue ported to CGI first, since we've already got
> that working in C. How much of the APR:: stuff (pools, brigades, etc.)
> in mp2 will run outside of mp2?
Eventually all of it. The only reason most of it doesn't at the moment is that
we use some functions available only in mod_perl.so. Those need to be
abstracted into a separate object so that it can be linked against APR.so.
__________________________________________________________________
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: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
[...]
> >>A::R 2 supports mp1?
> > In a manner of speaking, yes. Firstly, mod_apreq1.c needs to be
> > born, and secondly, the perl glue needs to be amended to subclass
> > from "Apache". Until both of those things happen, our perl glue must
> > fail to load for mp1. Of course, the error message could recommend
> > using libapreq-1.X here, but hey, why be pessimistic about it?
>
> That's very cool! So in the back of your mind you have an evil plan to
> drop the current libapreq-1 and maintain just one source for both
> Apache generation? ;)
Potentially, if there's sufficient interest. However, I'd really like
to see the perl glue ported to CGI first, since we've already got
that working in C. How much of the APR:: stuff (pools, brigades, etc.)
in mp2 will run outside of mp2?
--
Joe Schaefer
Re: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>> -die __PACKAGE__ . ": httpd must load mod_apreq.so first"
>>> - if __PACKAGE__->env ne "Apache::RequestRec";
>>> +if (\$ENV{MOD_PERL}) {
>>> + require mod_perl;
>>> + if (\$mod_perl::VERSION > 1.99) {
>>> + die __PACKAGE__ . ": httpd must load mod_apreq.so first"
>>> + if __PACKAGE__->env ne "Apache::RequestRec";
>>> + }
>>> + elsif (\$mod_perl::VERSION > 1.24) {
>>> + die __PACKAGE__ . ": httpd must load mod_apreq1.so first"
>>> + if __PACKAGE__->env ne "Apache";
>>
>>A::R 2 supports mp1?
>
>
> In a manner of speaking, yes. Firstly, mod_apreq1.c needs to be born,
> and secondly, the perl glue needs to be amended to subclass from "Apache".
> Until both of those things happen, our perl glue must fail to load for mp1.
> Of course, the error message could recommend using libapreq-1.X here,
> but hey, why be pessimistic about it?
That's very cool! So in the back of your mind you have an evil plan to drop
the current libapreq-1 and maintain just one source for both Apache generation? ;)
__________________________________________________________________
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: cvs commit: httpd-apreq-2/build xsbuilder.pl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> > -die __PACKAGE__ . ": httpd must load mod_apreq.so first"
> > - if __PACKAGE__->env ne "Apache::RequestRec";
> > +if (\$ENV{MOD_PERL}) {
> > + require mod_perl;
> > + if (\$mod_perl::VERSION > 1.99) {
> > + die __PACKAGE__ . ": httpd must load mod_apreq.so first"
> > + if __PACKAGE__->env ne "Apache::RequestRec";
> > + }
> > + elsif (\$mod_perl::VERSION > 1.24) {
> > + die __PACKAGE__ . ": httpd must load mod_apreq1.so first"
> > + if __PACKAGE__->env ne "Apache";
>
> A::R 2 supports mp1?
In a manner of speaking, yes. Firstly, mod_apreq1.c needs to be born,
and secondly, the perl glue needs to be amended to subclass from "Apache".
Until both of those things happen, our perl glue must fail to load for mp1.
Of course, the error message could recommend using libapreq-1.X here,
but hey, why be pessimistic about it?
--
Joe Schaefer