Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46004 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78499 invoked from network); 10 Nov 2009 19:07:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2009 19:07: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.117 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.117 us-mr1.zend.com Linux 2.4/2.6 Received: from [63.205.162.117] ([63.205.162.117:40825] helo=us-mr1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/77-38546-10AB9FA4 for ; Tue, 10 Nov 2009 14:07:47 -0500 Received: from us-gw1.zend.com (us-ex1.zend.net [192.168.16.5]) by us-mr1.zend.com (Postfix) with ESMTP id 5BF38E11E9; Tue, 10 Nov 2009 11:05:35 -0800 (PST) Received: from [192.168.16.66] ([192.168.16.66]) by us-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 11:07:42 -0800 Message-ID: <4AF9B9FE.1040701@zend.com> Date: Tue, 10 Nov 2009 11:07:42 -0800 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lukas Kahwe Smith CC: Guilherme Blanco , PHP Developers Mailing List References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org> <4AF9B5B8.90104@zend.com> <536BF944-AB9D-4B5F-86CB-B75D3C0D7F63@pooteeweet.org> In-Reply-To: <536BF944-AB9D-4B5F-86CB-B75D3C0D7F63@pooteeweet.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2009 19:07:42.0883 (UTC) FILETIME=[146D0F30:01CA6239] Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders From: stas@zend.com (Stanislav Malyshev) Hi! > yes that would solve the issue partially. the race condition would still > remain, but its admitedly a rare case .. well I guess not so rare if you I would have hard time thinking of application that deletes its own include files frequently from other processes and we are supposed to handle that deterministically. But even then worst thing would happen is that include fails. > (probably more used for some generated arrays and stuff like that). it > would also not solve the imho needless file system operations. You could cache file_exists using all kinds of external caching mechanisms if you want to. > that being said, i brought up adding such a flag to file_exists() a few > times before and each attempt has been shot down saying that fopen() > should have never gotten this flag and this portion of the code should > not mess with the include path. Why fopen() should have never gotten this flag? I don't remember any argument on that. Also, if we have include path I see no reason why we shouldn't have code that can work with it. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com