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
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
