Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.41 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <54027B6D.7060708@sugarcrm.com>
Date: Sun, 31 Aug 2014 12:18:08 +0800
Cc: PHP Internals <internals@lists.php.net>,
 jocelyn fournier <jocelyn.fournier@gmail.com>,
 Dmitry Stogov <dmitry@zend.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B3338F0D-6259-4A7B-9E1B-6912C2AA5194@gmail.com>
References: <54027B6D.7060708@sugarcrm.com>
To: Stanislav Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] destructors and output_buffering
From: tjerk.meesters@gmail.com (Tjerk Meesters)


On 31 Aug, 2014, at 9:33 am, Stas Malyshev <smalyshev@sugarcrm.com> =
wrote:

> Hi!
>=20
> I was looking at bug https://bugs.php.net/bug.php?id=3D67644 and it =
looks
> like we have a bit of a problem with output buffering and dtors on
> shutdown. Basically, right now our code looks like this:
>=20
> 	/* 2. Call all possible __destruct() functions */
> 	zend_try {
> 		zend_call_destructors(TSRMLS_C);
> 	} zend_end_try();
>=20
> 	/* 3. Flush all output buffers */
> 	zend_try {
> =09
> // And here we go flushing output buffers
>=20
> Now, since ob functions can have userland handlers, these handlers can
> create new objects. And these objects will not benefit from orderly =
dtor
> round that zend_call_destructors(TSRMLS_C) is providing - instead =
their
> dtors will be called from zend_objects_store_free_object_storage() and
> by then their environment may already be ruined and their dtors can =
not
> run properly.
>=20
> OTOH, moving __destruct after output buffers may not be good either, =
as
> dtors may output something.
>=20
> The problem seems to be resolved if I either duplicate
> zend_call_destructors(TSRMLS_C); after the output buffers flushing or =
put
> zend_objects_store_mark_destructed(&EG(objects_store) TSRMLS_CC);
> there.
>=20
> Of course, the second solution has the downside of not calling the =
dtors
> of objects that were created while flushing ob buffers. The
> zend_call_destructors would work but since output buffering is =
supposed
> to be shut down by then, I wonder if it won't also have bad =
consequences
> if these dtors do something with output buffering.
>=20
> I'm leaning towards the second solution - if you create the objects so
> late on shutdown stage, you shouldn't really expect them to be =
destroyed
> normally, otherwise the cycle would never end. However, we could
> consider the first option too. Any thoughts?

This is just a thought; could we delay the call to =
`zend_call_destructors` ONLY IF there=92s output buffering taking place =
(i.e. ob_get_level() > 0)?

> --=20
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20