Hi all,
Is it possible to make a zval persistent?
Currently I only found persistent resources or internal references used
in objects.
It would be very great for some userland applications to make a value
persistent whatever type it is.
Like the internal global "persistent_list" but this one is used for
persistent resources and I don't see how to use this one for zval's
directly. Additionally it's used internally with unknown hashes so it
could be dangerous to export it to userland.
Marc
Is it possible to make a zval persistent?
Nope.
Am 09.12.2014 um 20:03 schrieb Sara Golemon:
Is it possible to make a zval persistent?
Nope.
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.
Example:
persist_set($key, $value);
persist_get($key);
persist_has($key);
persist_list(); // list of persistent values
Am 09.12.2014 um 20:03 schrieb Sara Golemon:
Is it possible to make a zval persistent?
Nope.
Why?
There is a reference counter, which should be increased on put a value into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.Example:
persist_set($key, $value);
persist_get($key);
persist_has($key);
persist_list(); // list of persistent values
No, no the GC couldn’t. All zval data is stored in non-persistent memory allocated with emalloc(). The allocator destroys all of that at the end of the request/script execution. So you’d now have a dangling pointer. Kabewm!
Andrea Faulds
http://ajf.me/
Hi!
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.
Because memory which is allocated by the engine is freed at the end of
the request. You could copy the memory values but by then unless your
zvals are pretty simple you'll be pretty close to what the serializer
does, so no really big win there. The only advantage would be that when
you use it, if you're really careful, then you can use the data without
reallocating memory and freeing it. But it's not just putting a
flag/refcount on it, it requires some copying before that and some
careful setting of the refcounts too. So in theory, it can be done at
least for scalars and arrays (objects would be a problem since they need
class, and what if the class changed?) but it's not trivial.
--
Stas Malyshev
smalyshev@gmail.com
Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
Hi!
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.
Because memory which is allocated by the engine is freed at the end of
the request. You could copy the memory values but by then unless your
zvals are pretty simple you'll be pretty close to what the serializer
does, so no really big win there. The only advantage would be that when
you use it, if you're really careful, then you can use the data without
reallocating memory and freeing it. But it's not just putting a
flag/refcount on it, it requires some copying before that and some
careful setting of the refcounts too. So in theory, it can be done at
least for scalars and arrays (objects would be a problem since they need
class, and what if the class changed?) but it's not trivial.
Thanks for the explanation!
I'll experiment with it for scalars as extension.
Marc
IIRC, we used to support that back in ~2000s, but it got removed based on
the lack of usage and poor implementation.
Connection pooling could be a good usage of this if we manage to get this
working again.
[]s,
Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
Hi!
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.Because memory which is allocated by the engine is freed at the end of
the request. You could copy the memory values but by then unless your
zvals are pretty simple you'll be pretty close to what the serializer
does, so no really big win there. The only advantage would be that when
you use it, if you're really careful, then you can use the data without
reallocating memory and freeing it. But it's not just putting a
flag/refcount on it, it requires some copying before that and some
careful setting of the refcounts too. So in theory, it can be done at
least for scalars and arrays (objects would be a problem since they need
class, and what if the class changed?) but it's not trivial.Thanks for the explanation!
I'll experiment with it for scalars as extension.Marc
--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Hi!
Connection pooling could be a good usage of this if we manage to get
this working again.
Connection pooling is persisting external resources, usually, which can
be done with little regard to zvals, since zval for resource is just a
container holding an opaque pointer. A number of extensions do
persistent connections without really persisting zvals. However, in many
cases PHP is multiprocess, so pooling becomes kind of problematic here -
it may be hard or impossible to share connections between processes, and
if you have a lot of processes, keeping connection per process can
become expensive. That is to say, connection pooling is a different can
of worms :)
--
Stas Malyshev
smalyshev@gmail.com