Hi Stas,
Actually I would love flushing ob_start() in my own shutdown function,
but since my application is a library called in auto_prepend_file, I
have to protect ob_start() from being flushed too early by some wrong
code in the client application.
Hence I'm removing the PHP_OUTPUT_HANDLER_CLEANABLE,
PHP_OUTPUT_HANDLER_FLUSHABLE & PHP_OUTPUT_HANDLER_REMOVABLE, but then
I'm not able myself to flush the buffer :(
A great "new" feature would be to optionally give a name to a buffer,
and then allow to flush this buffer only if its name is passed through
ob_end_clean / ob_end_flush / ...
Thanks,
Jocelyn
Le 02/09/2014 21:29, Stas Malyshev a écrit :
Hi!
One line fix, nice :)
A quick question about how resources are freed :
if some variables are computed inside a singleton and read through a
myclass::instance()->get_my_variable(), should we expect to have those
variables available when calling ob_start() callbacks ?
From experiment, they are still available, but since
zend_call_destructors is called before ob_start(), I wonder if this is a
safe behaviour.
Generally, it would depend on when they were created. If they were
created before shutdown stage and you try to access them in OB shutdown
stage, it may be too late and the dtor may have been called for them
already. Doing too much stuff on shutdown is not really a good idea, as
you can not rely on resources being there. If you really need to do
something on shutdown, I'd advise register_shutdown_function() as it is
called first, before anything is really shut down. Relying on OB
handlers shutdown is not a good idea as by then at least part of the
shutdown happened. If you do something with OB handlers, I'd propose to
add a shutdown function that flushes the OB, so that you are sure
everything is wrapped up while the engine is still in predictable state
and not half-shutdown.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php