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:32:15 GMT
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