Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
Message-ID: <54037234.2030200@gmail.Com>
Date: Sun, 31 Aug 2014 21:06:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Nikita Popov <nikita.ppv@gmail.com>
CC: PHP Internals <internals@lists.php.net>, 
 Dmitry Stogov <dmitry@zend.com>
References: <54027B6D.7060708@sugarcrm.com> <CAF+90c_UuEmLiVE=501kz60X=E=L8V=Dwwka9jwfdPYaVDNbjQ@mail.gmail.com> <54036DEA.8060902@sugarcrm.com>
In-Reply-To: <54036DEA.8060902@sugarcrm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] destructors and output_buffering
From: jocelyn.fournier@gmail.com (jocelyn fournier)

Hi,

Another possible behaviour would be to trigger a fatal when trying to 
access a partially destroyed object in ob_start.
It took me a while to actually figure out why the memory was corrupted 
when doing stuff in ob_start() (even before playing with the AMQP lib).
Having a fatal would allow me to save a lot of time, and it should not 
introduce any BC issue since any existing code accessing a partially 
destroyed object could randomly crash at some point.

   Jocelyn



Le 31/08/2014 20:48, Stas Malyshev a écrit :
> 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.