Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76997 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27370 invoked from network); 31 Aug 2014 18:48:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Aug 2014 18:48:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:50044] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 21/25-30065-CED63045 for ; Sun, 31 Aug 2014 14:48:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 102DC80600; Sun, 31 Aug 2014 14:48:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 80F4480590; Sun, 31 Aug 2014 14:48:09 -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 18:48:09 GMT Message-ID: <54036DEA.8060902@sugarcrm.com> Date: Sun, 31 Aug 2014 11:48:10 -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: Nikita Popov 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: 7bit Subject: Re: [PHP-DEV] destructors and output_buffering From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Instead of iterating through all objects and setting a flag, can't we > set a global flag that object dtors are not called after this point? We could, but that would probably break some code that expects dtors to be actually called. E.g. in the bug, the library there seems to do a lot from the dtor, and if we just shut it down it may break the library. I don't think we can do this in 5.x. And I don't think we could get rid of the object flag in that case, since there could be cases of circular links that may still require this flag to avoid double calling of dtor (even not on shutdown). > This both solves the issue of new objects being created after the fact > and makes shutdown less expensive. I'm not sure expense of the shutdown is that big a deal though. Bigger deal is avoiding crashes on the shutdown. It seems to be that disabling dtors on all objects there is a bit too harsh - after all, for most of them it is fine, it's just those that linger after the OB code run _and_ have dependencies on other objects that create trouble. Another dtor round, for example, should resolve it, or just marking only those that linger as destroyed. This seems to have less impact that just banning dtors altogether. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/