perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <f...@redhotpenguin.com>
Subject Re: Fwd: 2012 updates
Date Thu, 24 Nov 2011 08:19:31 GMT
2011/11/22 Torsten Förtsch <torsten.foertsch@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


Mime
View raw message