# persistent zval

- Thread: https://externals.io/message/79511
- Original archive: https://news-web.php.net/php.internals/79511
- Started by Marc Bennewitz on 2014-12-09T18:58:10+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #79511 — Marc Bennewitz — 2014-12-09T18:58:10+00:00

URL: https://externals.io/message/79511#79511

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

---

## #79512 — Sara Golemon — 2014-12-09T19:03:30+00:00

URL: https://externals.io/message/79511#79512 · In reply to: #79511

> Is it possible to make a zval persistent?
>
Nope.

---

## #79514 — Marc Bennewitz — 2014-12-09T19:45:22+00:00

URL: https://externals.io/message/79511#79514 · In reply to: #79512

Am 09.12.2014 um 20:03 schrieb Sara Golemon:
> 
> > […]
> 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

---

## #79515 — Andrea Faulds — 2014-12-09T19:51:46+00:00

URL: https://externals.io/message/79511#79515 · In reply to: #79514

> 
> 
> 
> Am 09.12.2014 um 20:03 schrieb Sara Golemon:
> > […]
> 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/

---

## #79522 — Stanislav Malyshev — 2014-12-10T08:53:41+00:00

URL: https://externals.io/message/79511#79522 · In reply to: #79514

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

---

## #79576 — Marc Bennewitz — 2014-12-11T18:46:43+00:00

URL: https://externals.io/message/79511#79576 · In reply to: #79522

Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
> Hi!
>
> > […]
> 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

---

## #79577 — guilhermeblanco@gmail.com — 2014-12-11T18:52:21+00:00

URL: https://externals.io/message/79511#79577 · In reply to: #79576

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:
>
> > […]
> I'll experiment with it for scalars as extension.
>
> Marc
>
>
> --
> 
> 
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

---

## #79581 — Stanislav Malyshev — 2014-12-11T20:25:36+00:00

URL: https://externals.io/message/79511#79581 · In reply to: #79577

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