Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33644 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64992 invoked by uid 1010); 4 Dec 2007 15:56:51 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 64975 invoked from network); 4 Dec 2007 15:56:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Dec 2007 15:56:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=tony@daylessday.org; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tony@daylessday.org; sender-id=pass Received-SPF: pass (pb1.pair.com: domain daylessday.org designates 89.208.40.236 as permitted sender) X-PHP-List-Original-Sender: tony@daylessday.org X-Host-Fingerprint: 89.208.40.236 mail.daylessday.org Linux 2.6 Received: from [89.208.40.236] ([89.208.40.236:53134] helo=daylessday.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 48/36-09439-1C875574 for ; Tue, 04 Dec 2007 10:56:50 -0500 Received: from [192.168.3.87] (unknown [212.42.62.198]) by daylessday.org (Postfix) with ESMTP id AB4C964018A; Tue, 4 Dec 2007 18:56:46 +0300 (MSK) Message-ID: <475578BE.40908@daylessday.org> Date: Tue, 04 Dec 2007 18:56:46 +0300 User-Agent: Thunderbird 2.0.0.9 (X11/20071114) MIME-Version: 1.0 To: Andi Gutmans CC: Cristian Rodriguez , internals@lists.php.net References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> <7d5a202f0712031900i386f8964s675da26cc93af3fe@mail.gmail.com> <47550FAB.30002@daylessday.org> <698DE66518E7CA45812BD18E807866CEF890ED@us-ex1.zend.net> In-Reply-To: <698DE66518E7CA45812BD18E807866CEF890ED@us-ex1.zend.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Garbage collector patch From: tony@daylessday.org (Antony Dovgal) On 04.12.2007 18:31, Andi Gutmans wrote: > You may be right longer term but shorter term I still believe there may be stability issues with this patch some of which we haven't figured out. Although we did testing and found crash bugs I wouldn't trust our level of testing to deem it stable. If we go down the route of always on we could have a hidden ini file (not listed in php.ini-dist and phpinfo()) which we can advise to turn off if something goes wrong and once we can enough confidence that there aren't any lurking bugs we could remove it. You mean provide an ini setting to be able to turn it Off? But why do you call it "always On" then? And what's the difference comparing to what you've proposed earlier? Concerning the stability issues, I'd say we have quite good chance to make it stable enough, as (I hope) 5.3.0 is not going to be released for at least several months more. Companies that are especially concerned of performance/stability are encouraged to step forward and give us a hand. -- Wbr, Antony Dovgal