Stanislav Malyshev Wrote
SG>><?php
SG>> $fp1 = fopen('test', 'w');
SG>> $fp2 = $fp1; /* Still a single zval* and le->refcount == 1 */
SG>> $fp3 = &$fp1; /* Two zval*s now and le->refcount == 2 */
SG>>
SG>> fclose($fp1);
I think this was discussed before, though I may be mistaken. The problem
here is that you expect fclose to kill the resource, however $fp2 still
refers it.
Right, that was my whole point with le->refcount == 2
Looks like there should be two operations for resource - one is
usual delref called when variable is destroyed and second is "hard kill"
called when something like fclose is used and invalidating all referring
variables. I remember there were some issues with that, but I can't
rememebr what they were...
Right, that's what I meant by renaming the current zend_list_delete() to
zend_list_delref() and implementing a real zend_list_delete() that "hard
kills". This isolates the code that would need to be changed to
zval_dtor()'s call and perhaps one or two isolated cases like oci8 which
intentionally use the refcounting.
Not that I expect list destruction to be turned on its head over an edge
case mind you.
It might be nice to just have a zend_list_real_delete() though:
#define zend_list_real_delete(id) zend_hash_index_del(&EG(regular_list), id)
Obviously an extension which knows it wants to ignore refcounts can just do
this one liner itself (and would have to for stable versions), that just
feels a little sloppy though.
Wez Furlong Wrote:
We talked about this for the revised oci8 code; we
adopted the practice of ZVAL_NULL()ing the zval
just after we zend_list_delete() it, because the updated
oci8 codebase can return zvals that reference the same
underlying list resource.
That's an interresting approach, and makes perfect sense in the oci8 model
where (from the user's perspective) those truly are different connection
resources.
IMO, "hard kill" doesn't really fit in a system that
uses reference counts; you either use reference counts,
or don't.
The trouble with that theory is that functions like
fclose()/ftp_quit()/mysql_disconnect()/etc.... the user *does* expect the
resource to die. Having latent resource IDs sitting around when the
resource has been destructed is what the "Unknown" resource type is for.
Academic purity isn't going to change what the user experience is.
There are cases (particularly in streams) where we
hold the resource ID to guarantee that a pointer
remains valid. Hard kill would break the reference
counting contract and lead to a segv.
Not for nothin', but where? If the stream pointer is gone isn't that
because the resource_dtor method has been called and the stream has shutdown
properly? Once it's shutdown, what's left to try to use that pointer?
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
