Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
Message-ID: <54D1B5DB.8090602@gmail.com>
Date: Tue, 03 Feb 2015 22:02:03 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Xinchen Hui <laruence@php.net>, 
 PHP Internals <internals@lists.php.net>,
 Dmitry Stogov <dmitry@zend.com>
References: <CABBJUpdzJZFYwBh0trYMTFSBCDrjH66nJFrBRNhCQTGrpTRDgQ@mail.gmail.com>
In-Reply-To: <CABBJUpdzJZFYwBh0trYMTFSBCDrjH66nJFrBRNhCQTGrpTRDgQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [DICUSS]Cleanup resource handling APIs
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>     as you can see, we use "r" to receive a IS_RESOURCE type, that
> means, check the type in ZEND_FETCH_RESOURCE is overhead..

Except that some functions could receive "z" and decide if it's the
resource or not afterwards... But I guess you could rely on the code
that decides it to check. Some code would crash (or produce some very
bad memory corruption) if somebody would forget to add this check when
porting such extension. Is saving one branch worth it?

>    ZEND_API void *zend_fetch_resource(zval *passed_id, int default_id,
> const char *resource_type_name, int *found_resource_type, int
> num_resource_types, ...)
> 
>    we use va_args to passing resource type, that means, the rescue
> type arguments can not be passed by register but by stack.. which is a
> little low effiicient .

Is it that bad? Functions are passing arguments via the stack all
around. The interface with fetch(), fetch2(), fetch3(), fetch4(), etc.
looks a little clunky.

As for storing the value directly instead of having the list - it would
work for all cases except for two important ones:

1. Persistent resources - they need to be stored somewhere, and not in
zvals that are supposed to be dead at the end of the request.
2. Cleanup at the end for non-persistent ones - zvals may be lost and
not destructed in many exceptional situations. Not destructing the
resource may mean having a stale lock forever or consuming connections
or handles, etc. So there should be some mechanism allowing for
destroying all resources that are transient.

-- 
Stas Malyshev
smalyshev@gmail.com