Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>
Cc: "'Nicolas Grekas'" <nicolas.grekas+php@gmail.com>,
	"'Rowan Collins'" <rowan.collins@gmail.com>,
	<internals@lists.php.net>
References: <CAMUwpuTRzQHqznqKF-q=1Wy-Xnob9mra748E26YiZMKUa7-4DQ@mail.gmail.com>	<CAOWwgp=E_ap59FQ4SJYEMHa6oNbP4s1OhOvMRQnJwYoWhTYk1w@mail.gmail.com>	<024101d0cbaa$f864aa50$e92dfef0$@belski.net>	<55BDBE25.5050104@gmail.com>	<BLU436-SMTP102082244CAF2904DE6FE68E2880@phx.gbl>	<55BE5B89.5080103@gmail.com>	<CAOWwgpnWgpK59g9czFZMcg4rqY-jPHTTabLDMyYSH+2fJVj=Qg@mail.gmail.com>	<4557ED13-5446-45F1-8E04-A01F8A066600@gmail.com>	<CAOWwgp=F7HgVtpzGF6nszCJjxwtGLCMqLb9WqPOu3JgDW3XTsw@mail.gmail.com>	<EAA99075-3AE8-43CE-A746-FFA1112671EC@gmail.com>	<CAOWwgpkcU=X2Hx-OqG624DsncbAERfcvBSQdgutvC84wcj_xeA@mail.gmail.com>	<04cc01d0cdfa$24490e30$6cdb2a90$@belski.net> <CAAyV7nEi2uGnEaucChUUkHsffbGDZVLHswQk3B9LBZKs_BNQwg@mail.gmail.com>
In-Reply-To: <CAAyV7nEi2uGnEaucChUUkHsffbGDZVLHswQk3B9LBZKs_BNQwg@mail.gmail.com>
Date: Mon, 3 Aug 2015 22:35:48 +0200
Message-ID: <052301d0ce2b$fd21c9f0$f7655dd0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEZxEz2AZ24oXNpNMxONv1anupciAKrx7AyAi9zLxwCa9DPhwIfRl9pAjUtux0AZeGwBgJOG7UjARs9F90Bh7u/cADkj8uTAdsfzZ8CWio6+564Xddw
Content-Language: en-us
Subject: RE: [PHP-DEV] Exposing object handles to userland
From: anatol.php@belski.net ("Anatol Belski")

Hi Anthony,

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Monday, August 3, 2015 5:39 PM
> To: Anatol Belski <anatol.php@belski.net>
> Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>; Rowan Collins
> <rowan.collins@gmail.com>; internals@lists.php.net
> Subject: Re: [PHP-DEV] Exposing object handles to userland
>=20
> > - handle gets reused within the same script, even in same request.
> > There's no way to realize an object was garbage collected and
> > completely another one has the same id.\
>=20
> Well, one way that's handled is by storing a reference to the object.
> That way you know it's not collected.
>=20
> Basically, if you need to store something associated with an object's =
id, also
> store a reference to the object.
>=20
> This is how it's being done today when people use spl_object_hash() =
and
> associated objects (like SplObjectStorage).
>=20
Do you mean the id function would ref++? Or is it done in user space? =
IMHO the latter would be quite a subtle way. But SplObjectStorage should =
do it automatically, otherwise some entries would become invalid.

> > - what is done in the case the internal implementation was changed, =
it'll be
> probably hard to emulate but some apps will already depend on it.
>=20
> As long as the number returned is unique, it should be pretty straight =
forward.
> The contract isn't that a specific integer is returned, it's that it's =
a unique integer.
> So if object allocation changes the order that ids are issued, that =
shouldn't
> matter.
>
> And in practice we've seen that with a few of the changes in 7. A few =
internal
> tests may fail because they depend on the detail, but that's because =
they are bad
> tests, not the functionality changed.
>=20
I might be not getting it still, just if an id changes over time, isn't =
it not unique? A distinct relation object <=3D> id. Figurative - unique =
were a revision SHA in git, across all the branches. Concrete - in PHP =
it doesn't need to be over all requests, but within the same request? =
Maybe it needs a scope definition of unique. Coupling with disabling GC =
it would be of course.
=20
> > Maybe just incrementing a static variable were simple enough :) But =
IMHO
> these points need to be addressed prior the implementation. Maybe it's =
even not
> reliable enough to rely on the internal implementation.
>=20
> The problem here is that PHP is used by long-running processes as =
well. Imagine
> a server that runs for weeks. It could over the course of that time =
allocate
> trillions of objects. But since the handle is 32 bit (a signed int =
actually, which
> sounds wrong:
> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_objects_API.h#43 ), you =
can
> only have 2 billion objects allocated at one point in time.
>=20
> Even moving to a 64 bit counter, that's better but is it really =
necessary? You'd
> need to store the counter value for every single object. Meaning that =
you add 8
> bytes of memory to each object in the system. Would it be a better =
experience?
> Perhaps. Is it necessary? Not sure...
>=20
Yep, a global counter isn't a solution, just my unsuccessful joke. But =
the object handle seems to be unsigned =
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_types.h#_zend_object , also =
seeing how buckets are accessed. But also noticeable that the resource =
handle is signed, nevermind. Signed is probably more sensible when =
exporting directly in 32-bit build.

> I support leaving spl_object_hash() as is, and adding a
> spl_object_id() which is documented similarly and returns an integer =
for each
> object.
>=20
Yes, spl_object_id() were a twin of spl_object_hash(), by the =
information known today.

Regards

Anatol=20