Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28767 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85166 invoked by uid 1010); 12 Apr 2007 22:57:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 85151 invoked from network); 12 Apr 2007 22:57:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Apr 2007 22:57:47 -0000 Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.114 unknown Windows 2000 SP4, XP SP1 Received: from [63.205.162.114] ([63.205.162.114:10639] helo=us-ex1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/03-52881-A69BE164 for ; Thu, 12 Apr 2007 18:57:46 -0400 Received: from [127.0.0.1] ([192.168.16.109]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 15:57:47 -0700 Message-ID: <461EB95D.7030603@zend.com> Date: Thu, 12 Apr 2007 15:57:33 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrey Hristov CC: Lukas Kahwe Smith , internals@lists.php.net References: <461E4437.2090105@pooteeweet.org> <461E5674.5010107@hristov.com> In-Reply-To: <461E5674.5010107@hristov.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 22:57:47.0740 (UTC) FILETIME=[FD38D1C0:01C77D55] Subject: Re: [PHP-DEV] PHP6 todo list From: stas@zend.com (Stanislav Malyshev) > This is more like - ask ZE not to clean what it points to when it is > cleaning up the zval, and of course not to allow userland to change it. Well, actually persisting zvals between requests would be very problematic since it can not then use regular memory allocator (which is cleaned up at the request end). Which means the engine must know which allocator allocated the variable, otherwise we'd get a lot of trouble when mixing such variables in the same context. Also, it's not clear for me what such variable could be used for. I see only two potential uses: 1. Persistent resources. You don't really need zval then - persist the resource and allocate zval on need. Resources are refcounted separately, so no problem. 2. Caching. Here one would be much better to use external (with regard to the engine) caching solution - persisting zval would not gain that much since it's still limited to the process (which may not be either accessible or alive next time you need it) and overhead of converting regular zval to persistent one would be roughly the same as overhead for serializing zval into some form of cache. So I'd leave this to extensions. Are there any other reasons for persistent zvals? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/