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.foert...@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-unsubscr...@perl.apache.org
> For additional commands, e-mail: dev-h...@perl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
