You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philip M. Gollucci" <pg...@gmail.com> on 2011/11/22 22:27:08 UTC
Fwd: 2012 updates
-------- Original Message --------
Subject: 2012 updates
Date: Fri, 18 Nov 2011 18:09:58 +0000
From: Philip M. Gollucci <pg...@p6m7g8.com>
Organization: P6M7G8 Inc.
To: dev@perl.apache.org
If you haven't heard, I've stepped down as VP Infra, so I'm getting back
into some of the coding at ASF (horray!)
Coming up we/I need to do the following --
1) use dist.apache.org for releases and distribution
I'll handle this and update RELEASE accordingly.
2) drop support for perl < 5.10.0 [patch ready]
3) drop support for httpd 2.0.x and lower [patch ready]
4) stop waiting and merge branches/httpd24 and branches/threading to
trunk (Thanks Torsten!)
5) Stop versioning APR/APU 0.9, and start supporting apr where
apr/apr-util are the same thing
6) If you missed it httpd/apreq/trunk C bindings are not part of httpd
for 2.5.x+. The perl bindings need a new home. For the moment,
mod_perl is the only logical choice, so they will be relocated and
apreq will be 'closed down'
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Director Operations, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: Fwd: 2012 updates
Posted by Fred Moyer <fr...@redhotpenguin.com>.
2011/11/22 Torsten Förtsch <to...@gmx.net>:
> On Tuesday, 22 November 2011 21:27:08 Philip M. Gollucci wrote:
>> 1) use dist.apache.org for releases and distribution
>> I'll handle this and update RELEASE accordingly.
>> 2) drop support for perl < 5.10.0 [patch ready]
Can you post the patches? Generally +1 to the support changes.
>
> +1
>> 3) drop support for httpd 2.0.x and lower [patch ready]
>
> +1
>
>> 4) stop waiting and merge branches/httpd24 and branches/threading to
>> trunk (Thanks Torsten!)
>
> Not yet ready. It compiles and even works somehow. But all the new stuff in
> 2.4 is not ported yet, particularly the new per-module logging and the AAA
> stuff. Here we need to decide whether we want to implement the old perl side
> interface based on the new httpd interface or if it is better to pass the new
> interface through and drop the old interface for httpd 2.4. I think I'd prefer
> the second even though it means rewrite of a lot of tests and modules out
> there.
>
> As for threading, I think a rewrite with a slightly changed interface would be
> good:
>
> 1) take the refcount idea from the threading branch to attach interpreters
> 2) disconnect interpreter pools from vhosts:
>
> <PerlInterpPool Pool1>
> PerlSwitches ...
> </PerlInterpPool>
>
> <VHost ...>
> PerlUseInterpPool Pool1
> </VHost>
>
> <Location ...>
> PerlUseInterpPool Pool2
> </Location>
>
> 3) stop using multiple pointers to reference in principle the same thing.
> Currently the perl interpreter assinged to a thread is stored in a thread
> specific variable (PERL_SET_CONTEXT). Perhaps we can store our interpreter
> pool element in a variable in that interpreter. Thus, the interpreter knows
> everything to put itself back to the pool and we do not need lists to maintain
> interpreters in use. Instead each pool is simply an apr_queue_t of free
> interpreters.
>
> I am currently in a project that eats up all my time. So, don't expect much
> help from me till end of the year.
>
>> 5) Stop versioning APR/APU 0.9, and start supporting apr where
>> apr/apr-util are the same thing
>> 6) If you missed it httpd/apreq/trunk C bindings are not part of httpd
>> for 2.5.x+. The perl bindings need a new home. For the moment,
>> mod_perl is the only logical choice, so they will be relocated and
>> apreq will be 'closed down'
>
> I'd add
>
> 7) Have a look at the futex problem recently reported by Max Barry.
> 8) sort out the large file support reported by Marco Walther in the thread
> "[mp 2.0.5] Early core dump:-( OpenSolaris-x86, Apache 2.2.21 & Perl 5.14.1"
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Fwd: 2012 updates
Posted by Torsten Förtsch <to...@gmx.net>.
On Tuesday, 22 November 2011 21:27:08 Philip M. Gollucci wrote:
> 1) use dist.apache.org for releases and distribution
> I'll handle this and update RELEASE accordingly.
> 2) drop support for perl < 5.10.0 [patch ready]
+1
> 3) drop support for httpd 2.0.x and lower [patch ready]
+1
> 4) stop waiting and merge branches/httpd24 and branches/threading to
> trunk (Thanks Torsten!)
Not yet ready. It compiles and even works somehow. But all the new stuff in
2.4 is not ported yet, particularly the new per-module logging and the AAA
stuff. Here we need to decide whether we want to implement the old perl side
interface based on the new httpd interface or if it is better to pass the new
interface through and drop the old interface for httpd 2.4. I think I'd prefer
the second even though it means rewrite of a lot of tests and modules out
there.
As for threading, I think a rewrite with a slightly changed interface would be
good:
1) take the refcount idea from the threading branch to attach interpreters
2) disconnect interpreter pools from vhosts:
<PerlInterpPool Pool1>
PerlSwitches ...
</PerlInterpPool>
<VHost ...>
PerlUseInterpPool Pool1
</VHost>
<Location ...>
PerlUseInterpPool Pool2
</Location>
3) stop using multiple pointers to reference in principle the same thing.
Currently the perl interpreter assinged to a thread is stored in a thread
specific variable (PERL_SET_CONTEXT). Perhaps we can store our interpreter
pool element in a variable in that interpreter. Thus, the interpreter knows
everything to put itself back to the pool and we do not need lists to maintain
interpreters in use. Instead each pool is simply an apr_queue_t of free
interpreters.
I am currently in a project that eats up all my time. So, don't expect much
help from me till end of the year.
> 5) Stop versioning APR/APU 0.9, and start supporting apr where
> apr/apr-util are the same thing
> 6) If you missed it httpd/apreq/trunk C bindings are not part of httpd
> for 2.5.x+. The perl bindings need a new home. For the moment,
> mod_perl is the only logical choice, so they will be relocated and
> apreq will be 'closed down'
I'd add
7) Have a look at the futex problem recently reported by Max Barry.
8) sort out the large file support reported by Marco Walther in the thread
"[mp 2.0.5] Early core dump:-( OpenSolaris-x86, Apache 2.2.21 & Perl 5.14.1"
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org