Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16597 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2771 invoked by uid 1010); 10 Jun 2005 12:08:21 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 2756 invoked from network); 10 Jun 2005 12:08:21 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 10 Jun 2005 12:08:21 -0000 X-Host-Fingerprint: 195.197.172.115 gw01.mail.saunalahti.fi Linux 2.4/2.6 Received: from ([195.197.172.115:46680] helo=gw01.mail.saunalahti.fi) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id 5A/C9-21296-5B289A24 for ; Fri, 10 Jun 2005 08:08:21 -0400 Received: from nest.netphobia.fi (YZCLXVIII.dsl.saunalahti.fi [85.76.34.69]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 2E061E27F3 for ; Fri, 10 Jun 2005 15:08:19 +0300 (EEST) Received: from nest.netphobia.fi (nest.netphobia.fi [127.0.0.1]) by nest.netphobia.fi (8.13.1/8.13.1) with ESMTP id j5AC8KjT027422 for ; Fri, 10 Jun 2005 15:08:20 +0300 Received: from localhost (jani@localhost) by nest.netphobia.fi (8.13.1/8.13.1/Submit) with ESMTP id j5AC8KJs027419 for ; Fri, 10 Jun 2005 15:08:20 +0300 X-Authentication-Warning: nest.netphobia.fi: jani owned process doing -bs Date: Fri, 10 Jun 2005 15:08:20 +0300 (EEST) Reply-To: Jani Taskinen To: internals@lists.php.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Improving (?) PHP extension loading mechanism (was: Re: [PHP-CVS] cvs: php-src /ext/pdo pdo.c) (fwd) From: sniper@iki.fi (Jani Taskinen) 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 On Fri, 10 Jun 2005, Wez Furlong wrote: > 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. > > On 6/10/05, Jani Taskinen wrote: >> >> That patch of mine to the extension loading mechanism should fix this? >> Just add a dependancy of spl to pdo..and fix the 'delayed' startup >> routine. :) >> >> --Jani >> >> On Fri, 10 Jun 2005, Marcus Boerger wrote: >> >>> Hello 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. >>> >>>