This is more like - ask ZE not to clean what it points to when it is cleaning up the zval, and of course not to allow userland to change it.
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
