The patch in question can be found here:
http://www.php.net/~jani/patches/exts_loading_poc.patch
It is merely a quick proof-of-concept:
a) Separates PHP extension registering and startup routines
b) Adds an extra 'depends' entry to the module struct
c) Nukes the problematic AWK script (just for debugging so that I got
'wrong' order :)
If an extension has no dependancies, it will be registered and started
in same loop. If it has dependancies, it is registered but the startup
routines are not run. When all extensions are loaded and registered,
the startup routines are run for all the extensions (if one is already
started it's just skipped).
That patch needs a bit tuning up before it can be applied, given the
concept is approved, of course. :)
Needs to be done:
- All extensions requiring something from other extensions need to be
updated to have the deps in their module entry
- php_startup_extensions() needs to be more intelligent and loop through
until all dependancies are met and not just blindly try starting up
anything before extensios it depends on are started
- Make it quicker. I haven't done any benchmarks but it's pretty obvious
this does make the PHP startup slower..
--Jani
Yeah, that's what I'm thinking--would you mind posting that to
internals for consideration for 5.1?I think it would be a strong addition.
--Wez.
That patch of mine to the extension loading mechanism should fix this? Just add a dependancy of spl to pdo..and fix the 'delayed' startuproutine. :)
--JaniHello Wez,
we could check if spl is initialized and if not forcefully initialize it
in pdo's MINIT.marcus
Friday, June 10, 2005, 8:11:30 AM, you wrote:
wez Fri Jun 10 02:11:30 2005 EDT
Modified files:
/php-src/ext/pdo pdo.c
Log:
"Fix" PECL #4411
SPL is not initialized before PDO, so inheriting from SPL's runtime
exception class gives PDO a broken exception class.
We don't currently have a way to express this kind of "soft"
dependency in the build system, so I'm disabling inheriting from the
runtime exception for now.
Jani Taskinen wrote:
- Make it quicker. I haven't done any benchmarks but it's prettyobvious
this does make the PHP startup slower..
Ok, slower in what way - I mean, lets assume apache1.3 is being used
here, does it make the apachectl start slower, or does it make each
indivdual request slower ? If it's the later, I'd say it's slow enough
already. I'm having to ./buildconf --force and build custom modules
directly into php because of the speed issues for certain projects I'm
involved in - I'm not sure I like the idea of that speed difference
becoming more of an issue.
Though it sounds cool in principle :)
Hello Gareth,
Friday, June 10, 2005, 3:07:21 PM, you wrote:
Jani Taskinen wrote:
- Make it quicker. I haven't done any benchmarks but it's prettyobvious
this does make the PHP startup slower..
Ok, slower in what way - I mean, lets assume apache1.3 is being used
here, does it make the apachectl start slower, or does it make each
indivdual request slower ? If it's the later, I'd say it's slow enough
already. I'm having to ./buildconf --force and build custom modules
directly into php because of the speed issues for certain projects I'm
involved in - I'm not sure I like the idea of that speed difference
becoming more of an issue.
We are speaking of the MINIT pahse here that happens twice in apache 1.3
and once in apache 2.0 on server start. The RINIT phase that is being
executed on every request doesn't need it so far. However we should
add an entry for that phase too since we might sooner jump into this than
we want.
The current implementation has a runtime behavior of:
O(n)
The slowest approach would be:
O(n-m) + O(m^2) = O(n) + O(m^2) = O(m^2)
with
n being the number of modules and
m being the number of dependent modules
in real life it would turn out to be something like:
O(n) + C
with C being a small constant compared to the registering operation
itself.
Though it sounds cool in principle :)
Yeah it is.
--
Best regards,
Marcus mailto:mail@marcus-boerger.de