Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18718
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=YXAuMrSAhQUDMrch9CHfTJU21PkrbZ1qlBSSq9xQcWH5f2yjALCBGKWoqUOJcXcsqbFg/g2eK50hsT33+43NbkrITJfLLxM4UFIC+AfGXwfptZlyBzDKBJlDKjQ4uJUID9c9HsPpDGEgG+IV1/oViAD9zguDCxli0f+XzXyxvNM=
Message-ID: <4e89b42605090805185f916d96@mail.gmail.com>
Date: Thu, 8 Sep 2005 08:18:19 -0400
Reply-To: kingwez@gmail.com
To: Stanislav Malyshev <stas@zend.com>
Cc: Sara Golemon <pollita@php.net>, internals@lists.php.net
In-Reply-To: <Pine.LNX.4.62.0509081155150.19519@shire.zend.office>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <002301c5b40d$0f75a570$85901a44@lighthammer>
	<Pine.LNX.4.62.0509081155150.19519@shire.zend.office>
Subject: Re: [PHP-DEV] zend_list_delete() doesn't.
From: kingwez@gmail.com (Wez Furlong)

On 9/8/05, Stanislav Malyshev <stas@zend.com> wrote:
> SG>><?php
> SG>> $fp1 =3D fopen('test', 'w');
> SG>> $fp2 =3D $fp1; /* Still a single zval* and le->refcount =3D=3D 1 */
> SG>> $fp3 =3D &$fp1; /* Two zval*s now and le->refcount =3D=3D 2 */
> SG>>
> SG>> fclose($fp1);
>=20
> I think this was discussed before, though I may be mistaken.

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.

You could arrive at a similar kind of problem that Sara pointed out by
doing this:

$a =3D oci_connect(...);
$b =3D oci_connect(...); // $b is a different zval from $a, but refs the
same resource

oci_close($a);  // kills $a, but $b still owns a ref
oci_close($a);  // since $a still contains the resource id, this now
kills the resource,
                      // breaking $b

We made oci_close() set $a to NULL before returning, to avoid this
refcount skewing.

> The problem
> here is that you expect fclose to kill the resource, however $fp2 still
> refers it. Looks like there should be two operations for resource - one i=
s
> 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...

IMO, "hard kill" doesn't really fit in a system that uses reference
counts; you either use reference counts, or don't.  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.

--Wez.