Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <40E4B15C.5040100@stason.org>
Date: Thu, 01 Jul 2004 17:50:36 -0700
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617
MIME-Version: 1.0
To: Joe Schaefer <joe+gmane@sunstarsys.com>
Cc: dev@perl.apache.org
Subject: Re: [apr] dropping Apache2/ subdir for APR::*
References: <40E49C7A.8050605@stason.org>
 <874qor9sag.fsf@gemini.sunstarsys.com>
In-Reply-To: <874qor9sag.fsf@gemini.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> [...]
> 
> 
>>Of course for this to happen we need more hands to do the work,
>>and probably we shouldn't even start to do it now, instead spending
>>all the resources to get mp2 out first.
> 
> 
> +1 for putting this on the back burner.  Very soon there 
> will be two apr versions in the wild: 0.9.X and 1.0.X.  I
> think we should watch what sort of conflicts occur before 
> ripping APR:: out of mp2.
> 
> For instance, if APR:: were a separate release right now, 
> post apr-1 some user will install the APR:: package from
> CPAN, and then later on might want httpd-2.0.50 with modperl2.
> After installing httpd-2.0.50, mp2 will then need to either 
> tell this guy to replace httpd-2.0 with httpd-2.2, or reinstall 
> a new APR:: using apr-0 instead (which may break other APR:: 
> apps he's already using), or else mp2 will have to supply its 
> own APR:: modules, in a non-colliding fashion (probably via
> MP_INST_APACHE2=1, even though mp1 isn't even being discussed).

Good thinking, Joe. We may start to always install mp2 into Apache2/ then, 
including its APR libs, so that it's self-contained.

There are going to be various tricky bugs to figure out with the new things. I 
just had one when I tried:

perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; open my $fh, "<:APR", 
"/tmp/xxx", APR::Pool->new; print <$fh>'
APR::PerlIO::read: (9) Bad file descriptor at -e line ...

it took me time to figure out that the pool has gone out of scope and was 
destroyed by the time read was attempted. This fixed the problem:

perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; my $p = APR::Pool->new; open 
my $fh, "<:APR", "/tmp/xxx", $p; print <$fh>'

tricky. We may need to have much more defending code if we don't want to get a 
rain of bug reports. And writing it is not trivial at all :(

so in the case of open() we probably need to increment the refcount of the 
pool object and decrement it on close and hope that we don't get a leak anywhere.

-- 
__________________________________________________________________
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