Hi Anthony, > -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, August 3, 2015 5:39 PM > To: Anatol Belski <anatol....@belski.net> > Cc: Nicolas Grekas <nicolas.grekas+...@gmail.com>; Rowan Collins > <rowan.coll...@gmail.com>; internals@lists.php.net > Subject: Re: [PHP-DEV] Exposing object handles to userland > > > - 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.\ > > Well, one way that's handled is by storing a reference to the object. > That way you know it's not collected. > > Basically, if you need to store something associated with an object's id, also > store a reference to the object. > > This is how it's being done today when people use spl_object_hash() and > associated objects (like SplObjectStorage). > 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. > > 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. > I might be not getting it still, just if an id changes over time, isn't it not unique? A distinct relation object <=> 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. > > 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. > > 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. > > 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... > 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. > Yes, spl_object_id() were a twin of spl_object_hash(), by the information known today. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
