Yes, if we have persistent zvals we can use objects/arrays as
properties or constants for internal classes. I asked for this 2.5
years ago.
-Andrei
On Apr 12, 2007, at 3:57 PM, Stanislav Malyshev wrote:
Well, actually persisting zvals between requests would be very
problematic since it can not then use regular memory allocator
(which is cleaned up at the request end). Which means the engine
must know which allocator allocated the variable, otherwise we'd
get a lot of trouble when mixing such variables in the same context.
Also, it's not clear for me what such variable could be used for. I
see only two potential uses:
1. Persistent resources. You don't really need zval then - persist
the resource and allocate zval on need. Resources are refcounted
separately, so no problem.
2. Caching. Here one would be much better to use external (with
regard to the engine) caching solution - persisting zval would not
gain that much since it's still limited to the process (which may
not be either accessible or alive next time you need it) and
overhead of converting regular zval to persistent one would be
roughly the same as overhead for serializing zval into some form of
cache. So I'd leave this to extensions.
Are there any other reasons for persistent zvals?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
