Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76978 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72687 invoked from network); 31 Aug 2014 04:40:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Aug 2014 04:40:15 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.75 smtp75.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.75] ([108.166.43.75:46323] helo=smtp75.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/C2-50403-F27A2045 for ; Sun, 31 Aug 2014 00:40:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D1C9F300445; Sun, 31 Aug 2014 00:40:12 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp18.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 5735A300395; Sun, 31 Aug 2014 00:40:12 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net [108.66.6.48]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.2.10); Sun, 31 Aug 2014 04:40:12 GMT Message-ID: <5402A72B.5090805@sugarcrm.com> Date: Sat, 30 Aug 2014 21:40:11 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Tjerk Meesters CC: PHP Internals , jocelyn fournier , Dmitry Stogov References: <54027B6D.7060708@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] destructors and output_buffering From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is just a thought; could we delay the call to > `zend_call_destructors` ONLY IF there’s output buffering taking place > (i.e. ob_get_level() > 0)? That wouldn't help - imagine this: 1. ob_start is set 2. shutdown is starting 3. ob functions shut down, call function foo 4. function foo creates an object of class FooBar 5. ob shutdown ends, all output is flushed, etc. 6. FooBar::__destruct is run and tries to output something That scenario still may have a problem. I'll check more into if it's really a big deal outputting after OB shutdown (after all, some other things may lead to it too) but conditioning dtor move does not solve this problem. If it works this way we may as well move them there permanently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/