Edit report at http://bugs.php.net/bug.php?id=45421&edit=1
ID: 45421
Comment by: simpcl2008 at gmail dot com
Reported by: rpeters at icomproductions dot ca
Summary: Runtime equivilant of __FILE__
Status: Bogus
Type: Feature/Change Request
Package: *General Issues
Operating System: CentOS 4.3
PHP Version: 5.2.6
Block user comment: N
Private report: N
New Comment:
The patch of apc_auto_hardlinks_for_php_5.3.5.diff is to add a new key
word
"executed_filename" for PHP 5.3.5 .
When the following code is running:
<?php
echo executed_filename;
?>
In PHP Runtime, zend_get_executed_filename() is called to returned the
current
runtime filename and being displayed.
To fixed the apc hardlinks programs, the apc source code "apc_main.c"
should
also to be modified as follows:
--- APC-3.1.6/apc_main.c 2010-11-30 18:18:31.000000000 +0800
+++ APC-3.1.6-sae/apc_main.c 2011-04-27 15:56:34.000000000 +0800
@@ -559,6 +559,7 @@ static zend_op_array* my_compile_file(ze
if (h->type != ZEND_HANDLE_FILENAME) {
zend_llist_add_element(&CG(open_files), h);
}
+ op_array->filename = estrdup(filename);
return op_array;
}
if(APCG(report_autofilter)) {
Previous Comments:
------------------------------------------------------------------------
[2011-01-24 23:52:27] rpeters at icomproductions dot ca
I am once again asking the PHP devs to implement this feature, or at the
very least reconsider flagging this as "Bogus". This is a legitimate
feature request with a very significant upside, and marking it as
"Bogus" and then telling me to code it myself seems inappropriate.
Either you are against the request, or it should remain as a request
that a core developer can implement.
------------------------------------------------------------------------
[2009-08-19 21:51:20] rpeters at icomproductions dot ca
I don't have the expertise to develop a patch for PHP.
And the issue with PHP is that it's currently impossible for opcode
caches to correctly deal with __FILE__ in a hardlinked file.
This is due to the fact that __FILE__ (and __DIR__) is inherently
dynamic, but is compiled as a constant. _That's_ PHP's problem.
There are currently no workarounds or any other mechanisms for allowing
proper opcode caching. There is no way for a third party to work around
this PHP design flaw, only you have the power to change this.
Hence the _feature request_ (not bug report) that one be introduced.
I think it's in everyone's best interest if PHP opcaches are usable in
more situations than are currently possible.
------------------------------------------------------------------------
[2009-08-19 18:05:16] [email protected]
There isn't anything to fix in PHP, if you think we should do something
differently then please submit a patch and we'll review it.
------------------------------------------------------------------------
[2009-08-19 17:23:10] rpeters at icomproductions dot ca
So if I want this request re-examined, what do I need to do?
I think the support of opcode caches should be of importance to PHP devs
and users alike, and want to ensure this gets a fair examination rather
than being dismissed out of hand like it has been so far.
------------------------------------------------------------------------
[2008-07-09 15:29:27] rpeters at icomproductions dot ca
Since this has not received comment, I take this to mean that the PHP
developers do not care that their design choices make it impossible to
cache some PHP applications, even though they were designed using
recommended features that have no alternatives (like __DIR__).
I would have thought that ensuring there was an efficient way to cache
PHP applications, and thereby improve PHP's performance, would have a
high priority, and not be considered "bogus". I'm saddened to learn
otherwise.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=45421
--
Edit this bug report at http://bugs.php.net/bug.php?id=45421&edit=1
