Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002d01c5b480$715ed0e0$6c051fac@lighthammer>
To: "Stanislav Malyshev" <stas@zend.com>,
	"Wez Furlong" <kingwez@gmail.com>
Cc: <internals@lists.php.net>
References: <002301c5b40d$0f75a570$85901a44@lighthammer> <Pine.LNX.4.62.0509081155150.19519@shire.zend.office>
Date: Thu, 8 Sep 2005 07:19:58 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] zend_list_delete() doesn't.
From: pollita@php.net ("Sara Golemon")

>>> 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