perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <f...@redhotpenguin.com>
Subject Re: modperl - quo vadis?
Date Tue, 01 Feb 2011 07:37:38 GMT
Actually, I think it would be more appropriate to do 2.0.6 with the
Apache::* decoupling, then 2.2.0 for the APR::* decoupling.

2011/1/31 Fred Moyer <fred@redhotpenguin.com>:
> Another thing that comes to mind after rolling the 2.0.5 rc is that we
> should start shipping the Apache-* based modules separately as CPAN
> distributions when we release 2.0.6.
>
> The MY::test section in Makefile.PL will need to be overriden so that
> it skips the test suit if Apache-Test isn't present.  The code to do
> that is in a couple of other Makefile.PL files, and it pretty solid at
> this point.
>
> We should be moving towards more modularity; trying to get mod_perl
> 2.0.5 out has definitely seen the coupling of the Apache::* modules to
> it as a bottleneck.  I think that if we can remove the Apache::*
> modules from the distribution with 2.0.6, Gozer may be able to work
> his magic and decouple APR::* from mod_perl in 2.0.7.  Wouldn't that
> be cool :)
>
> 2011/1/28 Torsten Förtsch <torsten.foertsch@gmx.net>:
>> Hi all,
>>
>> a few questions that come up in my head every time when I think about modperl:
>>
>> - how long do we want to support old perl versions?
>>
>> For example, modern perls do not support anything but the perlio model. Stdio
>> was officially dropped in 5.8.7 or so. If you need to change some of the
>> related code in modperl it becomes really hard to test it. Older perls do not
>> compile in a modern environment and newer perls perhaps can be built without
>> perlio but the test suite will fail for sure.
>>
>> - can we really support windows?
>>
>> Do we have any developer who builds/tests/cares about modperl on windows? If
>> yes, I withdraw the question. If not, how can we claim modperl runs on
>> windows? I have tried to build apache & modperl on windows. But my last
>> encounter with it as a developer dates back to the mid-nineties. So I failed
>> badly already on the preliminaries. That doesn't mean anything if we have
>> someone on the team who can.
>>
>> BTW, could this someone please document in a fool-proof way (for me) how to
>> build modperl on windows starting with which compilers to use? Where do I get
>> or how do I build an usable openssl, that sort of stuff. Suppose you have a
>> freshly installed Vista or Win7 virtual machine.
>>
>>
>>
>> Perhaps, a few more points to discuss. They are a bit of a TODO list what
>> could be improved in modperl:
>>
>> - big: refactor threading code
>>  * implement a fixed sized interpreter pool
>>  * start perl interpreters before forking off worker children (use COW at
>>    least a bit)
>>  * implement PerlInterpInit and PerlInterpExit phases (like ChildInit/Exit)
>>    these hooks are run by the worker processes for each interpreter. Do we
>>    need also per thread init/exit phases? I doubt that, but ...
>>  * make -Dusemultiplicity -Uuseithreads possible
>>  * improve "PerlInterpScope handler" (mainly by writing test cases)
>>  * better configuration (instead of +Parent and similar):
>>    <PerlNameInterpreter myappv4>
>>      PerlSwitches ...
>>      PerlModule ...
>>      <Perl ...>
>>      </Perl>
>>    </PerlNameInterpreter>
>>    <PerlNameInterpreter myappv5>
>>      PerlSwitches ...
>>      PerlModule ...
>>      <Perl ...>
>>      </Perl>
>>    </PerlNameInterpreter>
>>    <VirtualHost ...>
>>      PerlUseInterpreter myapp4
>>      ...
>>    </VirtualHost>
>>    <Location ...>
>>      # perhaps we can offer different interpreters even here
>>      # at least starting at HeaderParser
>>    </Location>
>>  * implement interpreter usage monitoring via mod_status
>>
>> - smaller but not without pitfalls: implement a proper shutdown for
>>  $r->child_terminate
>>
>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
>>
>> - small: fix the leak in (reuse the brigade instead of allocating a new one
>>  from the pool)
>>
>>  while( my $chunk=get_some_chunk ) {
>>    $r->print($chunk);
>>    $r->rflush;
>>  }
>>
>> - small: I believe we have a leak with a perl that is compiled with
>>  "-Dusemultiplicity -Duseithreads" and code of the type
>>
>>    $r->push_handlers( Perl*Handler => sub {...} );
>>
>>  or in a .htaccess file
>>
>>    Perl*Handler "sub {...}"
>>
>>  where the actual handler is a anonymous subroutine or a closure.
>>
>> - implement a way to untie %ENV after fork() in a handler
>>
>> - there is Parse::Perl on CPAN. With a few tweaks that could be used or some
>>  ideas be adopted to improve Modperl::Registry
>>
>> - better support for other MPMs
>>
>> Sometimes it itches me to tackle the big one. But then that is minimum 4-8
>> weeks full time for me. With tests and documentation even longer. Last year I
>> couldn't afford that. I doubt this year. It's quite a large chunk of my yearly
>> income.
>>
>> Thoughts?
>>
>> 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