Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54299 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19322 invoked from network); 2 Aug 2011 23:59:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2011 23:59:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=frank@kromann.info; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=frank@kromann.info; sender-id=pass Received-SPF: pass (pb1.pair.com: domain kromann.info designates 98.189.231.18 as permitted sender) X-PHP-List-Original-Sender: frank@kromann.info X-Host-Fingerprint: 98.189.231.18 mail.webbypixel.com Received: from [98.189.231.18] ([98.189.231.18:40320] helo=mail.kromann.info) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 17/50-17431-97F883E4 for ; Tue, 02 Aug 2011 19:59:54 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.kromann.info (Postfix) with ESMTP id AAA1323F0B8 for ; Tue, 2 Aug 2011 16:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at localhost.localdomain Received: from mail.kromann.info ([127.0.0.1]) by localhost (mail.kromann.info [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OGW0d3Sjj2IT for ; Tue, 2 Aug 2011 16:59:34 -0700 (PDT) Received: from fmk.mascorp.com (206-190-75-9.static.twtelecom.net [206.190.75.9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: frank) by mail.kromann.info (Postfix) with ESMTP id 7871323F0B7 for ; Tue, 2 Aug 2011 16:59:34 -0700 (PDT) Message-ID: <4E388F66.5090200@kromann.info> Date: Tue, 02 Aug 2011 16:59:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: internals@lists.php.net References: <4E3814C9.2020407@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Weak References From: frank@kromann.info ("Frank M. Kromann") Adding a new feature to the latest version of PHP will not make it available to users of shared hosting. Many of these are running on older versions and it takes time for them to get updated to the latest. - Frank On 8/2/11 11:06 AM, Hannes Landeholm wrote: > I've talked to Etienne and he still believes we should vote on this so the > vote is still up. He just replied to quickly. If the vote fails the patch > can still be implemented in a PECL extension. There's no point canceling the > vote or the RFC - it's still valid and ongoing, and there is still time for > discussion. > > The problem is that PECL is not an option for all users. If you're using > shared hosting and otherwise don't have control over what extensions is > loaded or not then essentially you'll be unable to use a framework that > takes advantage of weak references. That's the reality of many freelancing > developers and small-scale sites out there. It's especially problematic for > framework designers that builds ORM-layers - they can't tell their users "oh > btw you need to install this non standard PECL extension for it to work". Or > rather, you can but then the user will be angry. > > I don't think "because they can" is a good argument for why features should > generally be outsourced as PECL extensions. Complex, experimental stuff that > solves specific integration or performance problems is great for PECL. But > generic object orientation design fundamentals should be implemented in the > core since people rather have their framework leak a bit more memory (and > risk running out of it in edge cases) or design their application more > clumsy than depend on a non-standard PECL extension. It's about allowing > people to do elegant design. A good developer would choose compatibility > over elegant design any day - so if the language wants people to do design > great applications the language needs to provide those tools natively. > > I realize I need to provide some kind of realistic scenario for you to > understand so let's put ourselves in the shoes of Joe Codeguy - he's > currently designing the an application that will edit inventory details at a > small company with 10 employees. It is hosted at a shared hosting provider > since they are running a tight budget. They can't afford their own servers > or an IT guy. The employers regularly login to the application and updates > the inventory. Joe Codeguy has designed the application so that there are > one Product class that is loaded from the database where each "products" > table row corresponds to a product. Certain function in the application runs > a MySQL procedure that updates a certain complex selection of products in > the products database rendering the currently loaded products in memory > obsolete since they might have been updated. After this procedure runs all > Product class objects in memory will need to be reloaded. Joe Codeguy fixes > this by implementing the observer pattern (PEAR Event_Dispatcher) so that > whenever a Product is loaded or created it registers itself on a global > event called "EVENT_PRODUCT_RELOAD". He then proceeds to trigger the event > whenever the complex MySQL procedure updates the database table. Everything > seems to be working fine so he deploys the application. One days later the > customer complains that a certain critical operation no longer works. Joe > then find a subroutine while debugging that loops trough a quite large > selection of thousands of products one by one and makes some complicated > calculations. During this loop the application faces a out of memory > condition. Joe thinks this is strange because it only operates on one > product at a time. He then realizes that the observer registration prevents > the products from being garbage collected properly since they are strongly > referenced by Event_Dispatcher. Thankfully PHP implements weak references so > he can correct Event_Dispatcher to use weak referencing instead. However > it's outsourced into a PECL extension and since Joe cannot install > extensions into the production server he is forced to use unset hacks in the > faulty loops to correct the issue. Joe deploys the application again and can > only hope that this was the only loop that triggered the memory problem and > that the application doesn't crash anywhere else when the products table > grows larger. > > Also even if an application doesn't run out of memory there might be a > serious performance impact from the memory leaked by objects that can't be > collected properly. If an application peaks at 15 MB instead of 25 MB, the > server can run 40% more child threads in parallel. > > Regards, > > ~Hannes > > On 2 August 2011 17:16, Lester Caine wrote: > >> The fast development root does seem to have been a little screwed up >> recently, but if there is nothing in an extension that requires direct >> access to the core and that extension CAN simply be enabled as required, >> then pecl is the way to go? We do need the pecl area to be properly included >> in the build process with windows builds being created just as they used to >> be, but the process is working fine for APC and perhaps the plan should be >> to moving some more extensions that are being worked on between PHP releases >> into the pecl process? It used to be that many of the extensions I used were >> managed in pecl ... and I'd be quite happy if they moved back there. There >> is nothing stopping 'Weak References' being added by those who want them ... >> but I can't see the point myself when running scripts live. >> >> -- >> Lester Caine - G8HFL >> ----------------------------- >> Contact - http://lsces.co.uk/wiki/?page=**contact >> L.S.Caine Electronic Services - http://lsces.co.uk >> EnquirySolve - http://enquirysolve.com/ >> Model Engineers Digital Workshop - http://medw.co.uk// >> Firebird - http://www.firebirdsql.org/**index.php >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>