Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23842 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63344 invoked by uid 1010); 1 Jun 2006 04:53:15 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63329 invoked from network); 1 Jun 2006 04:53:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Jun 2006 04:53:15 -0000 X-PHP-List-Original-Sender: steph@zend.com X-Host-Fingerprint: 192.38.9.232 gw2.emini.dk Linux 2.4/2.6 Received: from ([192.38.9.232:11540] helo=gw2.emini.dk) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id E8/CA-07504-BB27E744 for ; Thu, 01 Jun 2006 00:53:15 -0400 Received: from foxbox (unknown [84.228.79.24]) by gw2.emini.dk (Postfix) with ESMTP id 775ADAEBA2; Thu, 1 Jun 2006 06:53:11 +0200 (CEST) Message-ID: <09f801c68536$f18f0cd0$6602a8c0@foxbox> Reply-To: "Steph Fox" To: "Frank M. Kromann" , "Andi Gutmans" Cc: "'internals'" , "'Antony Dovgal'" , "Dmitry Stogov" , "'Xuefer'" References: <11490874854760000@9866357972520000.9866341568840000><091901c684c6$390ef370$6602a8c0@foxbox> <7.0.1.0.2.20060531212500.03758ec8@zend.com> Date: Thu, 1 Jun 2006 06:50:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI From: steph@zend.com ("Steph Fox") >>Yes, it would, given the root cause - but would you really want to break >>the whole of PHP for an academic exercise? > > It's not really an academic exercise. If we know there's a bug someplace > we should at least look into it and try and understand it. Frank's referring to Zeev's three-years-ago decision to simply opt out of tsrm_shutdown() here... he's suggesting we revert it. > Then if we decide to remove the trsm_shutdown call for a good reason > (circular dependency, blah blah blah) then we can do that and put a nice > fat comment on why it's the right thing to do. But I do think it's > benefical to try and understand what's happening. Fine, but breaking working code while you're trying to understand what's happening is far from beneficial to our users. Can't we at least #0 it? > > Andi