Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
In-Reply-To: <4AF9B9FE.1040701@zend.com>
Date: Tue, 10 Nov 2009 20:16:52 +0100
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <40A3B652-6B6A-49C1-9481-40AA6EC7537A@pooteeweet.org>
References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org> <bcb7aa500911100900n7c7c5dbexf5ad369134584c58@mail.gmail.com> <4AF9B5B8.90104@zend.com> <536BF944-AB9D-4B5F-86CB-B75D3C0D7F63@pooteeweet.org> <4AF9B9FE.1040701@zend.com>
To: Stanislav Malyshev <stas@zend.com>
Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 10.11.2009, at 20:07, Stanislav Malyshev wrote:

> 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.

there are many approaches to caching, one of which is delete to  
invalidate and regenerate before the next use. again as the RFC makes  
it clear .. the purpose is to be able to differentiate between a  
syntax error and a missing file.

>> (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.

sure .. but that requires yet more code. but in that case i might as  
well iterate over the include path to be able to determine the  
absolute path and cache that, which is something i also want to enable  
in an efficient manner with the optional addition of returning the  
file loaded instead of true in case the file does not return anything  
explicitly. again something that i mentioned in the RFC.

>> 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.


IIRC Derick was one of the most vocal against adding this to  
file_exists() and complaining about the fact that its even available  
for fopen().

regards,
Lukas Kahwe Smith
mls@pooteeweet.org