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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
