Re: [PHP-DEV] Closures and $this
2009/12/15 Christian Seiler chris...@gmx.net: Hello again, Discuss away! I'm a little disappointed by the non-outcome of this debate. Very few people have responded and most of them seem to agree proposal (A) should be implemented, perhaps with the additional bind/bindTo as in my proposal and perhaps not. The problem here is: (A) was exactly the thing that was implemented and that people started to have a problem with as soon as the first or second beta of PHP 5.3 was released. And because the feedback came in so late, Lukas Johannes decided to remove $this support from closures for PHP 5.3 in order to be able to decide that later on. So basically we're at the same point where we were a little more year ago: There's an RFC for this (the semantics of $this support were discussed in the original closures RFC!) and the people who read it on internals@ support it. However, I predict that if we implement exactly the semantics that the RFC proposes, we will get into the same discussion we had with PHP 5.3 just before the release of PHP 6... (or 5.4 should there be one). So: What now? Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php How much of a use case is binding $this to closures (personally, I think this is quite a common usage, but I've been using JavaScript so maybe I've got the wrong head on). But, if there are significant technical/internal issues with regard to binding $this to closures, what about (and I'm expecting the usual shoot down here as I obviously know squat) NOT binding closures at all (option 0). Instead get traits working. A trait (as I understand things from the rfc) from a userland perspective seems to offer some very similar features of bound closures. Binding a closure to an object, to all intents and purposes extends the object with a new callable method. Traits do that too. Completely differently - agreed - but a class with a trait has a new method. An object with a bound closure has a new method (ish). I know there are differences, but because it had been previously decided to NOT include bound closures, changing that (surely only at 6 or at a BIG push 5.4 if and when) would have to be considered so not to break BC (though I can't really see how allowing $this to be bound would break BC as you can't bind $this at the moment). At this late stage, is this a realistic option? If this _IS_ an option then I'd vote for this. I'd much rather have traits than bound closures. Regards, Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] typo: make arguments list clearer
Hi tony,
here is a patch which makes php-fpm consistent about command line arguments.
As php-fpm won't handle file execution from command line, it's not
necessary to let extra or wrong arguments to be used. With this patch,
it returns usage() if it's not a valid arg.
++ Jerome
Index: sapi/fpm/fpm/fpm_main.c
===
--- sapi/fpm/fpm/fpm_main.c (révision 292207)
+++ sapi/fpm/fpm/fpm_main.c (copie de travail)
@@ -145,26 +145,16 @@
static zend_module_entry cgi_module_entry;
static const opt_struct OPTIONS[] = {
- {'a', 0, interactive},
- {'C', 0, no-chdir},
{'c', 1, php-ini},
{'d', 1, define},
{'e', 0, profile-info},
- {'f', 1, file},
{'h', 0, help},
{'i', 0, info},
- {'l', 0, syntax-check},
{'m', 0, modules},
{'n', 0, no-php-ini},
- {'q', 0, no-header},
- {'s', 0, syntax-highlight},
- {'s', 0, syntax-highlighting},
- {'w', 0, strip},
{'?', 0, usage},/* help alias (both '?' and 'usage') */
{'v', 0, version},
{'y', 1, fpm-config},
- {'z', 1, zend-extension},
- {'T', 1, timing},
{'-', 0, NULL} /* end of args */
};
@@ -971,29 +961,18 @@
prog = php;
}
- php_printf( Usage: %s [-q] [-h] [-s] [-v] [-i] [-f file]\n
- %s file [args...]\n
- -a Run interactively\n
- -b address:port|port Bind Path for
external FASTCGI Server mode\n
- -C Do not chdir to the
script's directory\n
+ php_printf( Usage: %s [-n] [-e] [-h] [-i] [-m] [-v] [-c file]
[-d foo[=bar]] [-y file]\n
-c path|file Look for php.ini file in
this directory\n
-n No php.ini file will be
used\n
-d foo[=bar] Define INI entry foo with
value 'bar'\n
-e Generate extended
information for debugger/profiler\n
- -f fileParse file. Implies
`-q'\n
-h This help\n
-i PHP information\n
- -l Syntax check only (lint)\n
-m Show compiled in modules\n
- -q Quiet-mode. Suppress HTTP
Header output.\n
- -s Display colour syntax
highlighted source.\n
-v Version number\n
- -w Display source with
stripped comments and whitespace.\n
-y, --fpm-config file\n
- Specify alternative path to
FastCGI process manager config file.\n
- -z fileLoad Zend extension
file.\n
- -T count Measure execution time of
script repeated count times.\n,
- prog, prog);
+ Specify alternative path to
FastCGI process manager config file.\n,
+ prog);
}
/* }}} */
@@ -1662,6 +1641,7 @@
exit_status = 0;
goto out;
+ default:
case 'h':
case '?':
cgi_sapi_module.startup(cgi_sapi_module);
@@ -1693,6 +1673,19 @@
goto out;
}
}
+
+ /* No other args are permitted here as there is not interactive mode */
+ if (argc != php_optind) {
+ cgi_sapi_module.startup(cgi_sapi_module);
+ php_output_startup();
+ php_output_activate(TSRMLS_C);
+ SG(headers_sent) = 1;
+ php_cgi_usage(argv[0]);
+ php_end_ob_buffers(1 TSRMLS_CC);
+ exit_status = 0;
+ goto out;
+ }
+
php_optind = orig_optind;
php_optarg = orig_optarg;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] bug: some event from parent might be triggered by children
hi tony,
this patch correct a behaviour that could happened randomly, depending
on the event lib used (epoll, poll, kqueue, ...). There is some case
in which an event created by the parent process can be triggered in a
child.
This patch corrects this by checking if fpm_globals.is_child is set
and return directly in this case.
++ Jerome
Index: sapi/fpm/fpm/fpm_process_ctl.c
===
--- sapi/fpm/fpm/fpm_process_ctl.c (révision 292207)
+++ sapi/fpm/fpm/fpm_process_ctl.c (copie de travail)
@@ -296,6 +296,11 @@
{
struct fpm_worker_pool_s *wp;
+ /* If it's child, return immediately */
+ if (fpm_globals.is_child) {
+ return;
+ }
+
for (wp = fpm_worker_all_pools; wp; wp = wp-next) {
int terminate_timeout = wp-config-request_terminate_timeout;
int slowlog_timeout = wp-config-request_slowlog_timeout;
@@ -316,6 +321,11 @@
struct fpm_child_s *last_idle_child = NULL;
int i;
+ /* If it's child, return immediately */
+ if (fpm_globals.is_child) {
+ return;
+ }
+
for (wp = fpm_worker_all_pools; wp; wp = wp-next) {
struct fpm_child_s *child;
int idle = 0;
@@ -398,6 +408,11 @@
struct timeval tv = { .tv_sec = 0, .tv_usec = 13 };
struct timeval now;
+ /* If it's child, return immediately */
+ if (fpm_globals.is_child) {
+ return;
+ }
+
if (which == EV_TIMEOUT) {
evtimer_del(heartbeat);
fpm_clock_get(now);
@@ -415,6 +430,11 @@
struct timeval tv = { .tv_sec = 0, .tv_usec =
FPM_IDLE_SERVER_MAINTENANCE_HEARTBEAT };
struct timeval now;
+ /* If it's child, return immediately */
+ if (fpm_globals.is_child) {
+ return;
+ }
+
if (which == EV_TIMEOUT) {
evtimer_del(heartbeat);
fpm_clock_get(now);
Index: sapi/fpm/fpm/fpm_stdio.c
===
--- sapi/fpm/fpm/fpm_stdio.c(révision 292207)
+++ sapi/fpm/fpm/fpm_stdio.c(copie de travail)
@@ -84,6 +84,11 @@
int in_buf = 0;
int res;
+ /* If it's child, return immediately */
+ if (fpm_globals.is_child) {
+ return;
+ }
+
#if 0
zlog(ZLOG_STUFF, ZLOG_DEBUG, child %d said %s, (int) child-pid,
is_stdout ? stdout : stderr);
#endif
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] typo: make arguments list clearer
On 16.12.2009 18:20, Jérôme Loyet wrote: Hi tony, here is a patch which makes php-fpm consistent about command line arguments. As php-fpm won't handle file execution from command line, it's not necessary to let extra or wrong arguments to be used. With this patch, it returns usage() if it's not a valid arg. Thanks. I was going to do it myself, but it's nice that you've managed to do it first =) -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] bug: some event from parent might be triggered by children
On 16.12.2009 18:33, Jérôme Loyet wrote: hi tony, this patch correct a behaviour that could happened randomly, depending on the event lib used (epoll, poll, kqueue, ...). There is some case in which an event created by the parent process can be triggered in a child. Some case? Could you elaborate? The patch certainly does no harm, but maybe it's worth investigating why parent events are triggered in child processes? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
Richard Quadling wrote: How much of a use case is binding $this to closures (personally, I think this is quite a common usage, but I've been using JavaScript so maybe I've got the wrong head on). But, if there are significant technical/internal issues with regard to binding $this to closures, what about (and I'm expecting the usual shoot down here as I obviously know squat) NOT binding closures at all (option 0). Instead get traits working. *snip* If I recall the trait discussion properly, traits are a compile-time thing. Closure binding is a run-time thing. They are not comparable and one cannot really be used to implement the other. (Well, hypothetically bound closures could kinda-sorta replicate traits, but it would be a pretty lousy way of doing it as you get no compile-time enforcement or interface support.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] bug: some event from parent might be triggered by children
Le 16 décembre 2009 16:54, Antony Dovgal t...@daylessday.org a écrit :
On 16.12.2009 18:33, Jérôme Loyet wrote:
hi tony,
this patch correct a behaviour that could happened randomly, depending
on the event lib used (epoll, poll, kqueue, ...). There is some case
in which an event created by the parent process can be triggered in a
child.
Some case?
I had this bug several time doing differents stuff. So I don't have a
real case to explain here (I can search).
Could you elaborate?
It's related to the missing event_init after forking a child. In
fpm_children_make(), we have:
fork()
event_init() /* to reinit libevent, necessary for epoll */
if (in_event_loop) event_loop_break();
I think the bug appears when event_init has been added recently. As
event_init reinitiated the libevent environment, the
event_loop_break() call has no more effect as it refers to a new
environment. So the main loop is still running and event can be
triggered by both parent and children.
The solution is to move the event_init just after the call. Moreover,
I think the previous patch (which add verification on
fpm_globals.child) should be included also as it secure the
application, just in case :)
++ Jerome
Index: sapi/fpm/fpm/fpm_children.c
===
--- sapi/fpm/fpm/fpm_children.c (révision 292214)
+++ sapi/fpm/fpm/fpm_children.c (copie de travail)
@@ -373,12 +373,12 @@
switch (pid) {
case 0 :
- event_init(); /* reopen epoll descriptor */
fpm_child_resources_use(child);
fpm_globals.is_child = 1;
if (in_event_loop) {
fpm_event_exit_loop();
}
+ event_init(); /* refresh libevent environment */
fpm_child_init(wp);
return 0;
The patch certainly does no harm, but maybe it's worth investigating why
parent events are triggered in child processes?
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] bug when requesting a non existing file
There is a bug in fpm_main.c. After accepting a request, it's
initialized and SG(request_info).path_translated must be set. If it's
not set (NULL) nothing is done and the php_execute_script is called
without having php_fopen_primary_script() called. It causes segfault:
1- call several time a non existant page (/noexistent.php)
2- call several time an existant page (/test.php)
3- call a non existant page (/noexistent.php) -- the child handling
this request segfaults
The solution is to return a 404 when SG(request_info).path_translated is NULL.
By the way, it corrects a non desired feature (bug ?) as well. When
calling a non existent value, it returns a 404 with the following
message
br /
bWarning/b: Unknown: Filename cannot be empty in bUnknown/b
on line b0/bbr /
br /
bFatal error/b: Unknown: Failed opening required ''
(include_path='.:/usr/local/lib/php') in bUnknown/b on line
b0/bbr /
++ Jerome
Index: sapi/fpm/fpm/fpm_main.c
===
--- sapi/fpm/fpm/fpm_main.c (révision 292212)
+++ sapi/fpm/fpm/fpm_main.c (copie de travail)
@@ -1783,24 +1783,32 @@
return FAILURE;
}
- if (SG(request_info).path_translated) {
- if (php_fopen_primary_script(file_handle
TSRMLS_CC) == FAILURE) {
- zend_try {
- if (errno == EACCES) {
-
SG(sapi_headers).http_response_code = 403;
- PUTS(Access
denied.\n);
- } else {
-
SG(sapi_headers).http_response_code = 404;
- PUTS(No input file
specified.\n);
- }
- } zend_catch {
- } zend_end_try();
- /* we want to serve more requests if
this is fastcgi
-* so cleanup and continue, request
shutdown is
-* handled later */
+ /* If path_translated is NULL, terminate here with a
404 */
+ if (!SG(request_info).path_translated) {
+ zend_try {
+ SG(sapi_headers).http_response_code =
404;
+ } zend_catch {
+ } zend_end_try();
+ goto fastcgi_request_done;
+ }
- goto fastcgi_request_done;
- }
+ /* path_translated exists, we can continue ! */
+ if (php_fopen_primary_script(file_handle TSRMLS_CC) ==
FAILURE) {
+ zend_try {
+ if (errno == EACCES) {
+
SG(sapi_headers).http_response_code = 403;
+ PUTS(Access denied.\n);
+ } else {
+
SG(sapi_headers).http_response_code = 404;
+ PUTS(No input file
specified.\n);
+ }
+ } zend_catch {
+ } zend_end_try();
+ /* we want to serve more requests if this is
fastcgi
+* so cleanup and continue, request shutdown is
+* handled later */
+
+ goto fastcgi_request_done;
}
fpm_request_executing();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bug when requesting a non existing file
Committed, thanks. I guess we can also move from the list to private mails and IRC (EFNet, #php.pecl) as I'm sure not many of internals@ subscribers are interested in FPM patches at the moment. On 16.12.2009 20:13, Jérôme Loyet wrote: There is a bug in fpm_main.c. After accepting a request, it's initialized and SG(request_info).path_translated must be set. If it's not set (NULL) nothing is done and the php_execute_script is called without having php_fopen_primary_script() called. It causes segfault: 1- call several time a non existant page (/noexistent.php) 2- call several time an existant page (/test.php) 3- call a non existant page (/noexistent.php) -- the child handling this request segfaults The solution is to return a 404 when SG(request_info).path_translated is NULL. By the way, it corrects a non desired feature (bug ?) as well. When calling a non existent value, it returns a 404 with the following message br / bWarning/b: Unknown: Filename cannot be empty in bUnknown/b on line b0/bbr / br / bFatal error/b: Unknown: Failed opening required '' (include_path='.:/usr/local/lib/php') in bUnknown/b on line b0/bbr / ++ Jerome -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
On Tue, Dec 15, 2009 at 08:46:44PM +0100, Christian Seiler wrote: (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) +1 for A+ with class scope option 2 I'm a bit torn on how clone should be addressed - there's already some things that (IMO) have a fairly high WTF factor on cloning, and I'd hate to see more of that introduced. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.1 reference parameter regression
Stanislav Malyshev wrote: Hi! Test cases can be found here:http://bugs.php.net/bug.php?id=50394. It seems to me that a special case would be needed to restore the behaviour seen in PHP 5.3.0. I'll check it out, seems to be valid use case, we should find some solution for that. There seems to have been no progress on this. Is there anything I can do to help? -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.1 reference parameter regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Tim, There seems to have been no progress on this. Is there anything I can do to help? just for the record: why does MediaWiki rely on a feature Call-Time-Pass-By-Reference that is deprecated since PHP 4.0.0 - Yes exactly 4.0.0 What happened between 5.3.0 and 5.3.1 is that stas killed that feature for internal functions to work around a big security problem in the design of the Zend Engine. Considering the fact that the feature is DEPRECATED since 4.0.0 it would even be okay to kill it for all functions. Stefan Esser - -- SektionEins GmbH stefan.es...@sektioneins.de Eupener Straße 150 Tel: 0221 / 29282931 50933 Köln Fax: 0221 / 29282935 http://SektionEins.de/ Firmensitz Eupener Straße 150 50933 Köln Registergericht Amtsgericht Köln HRB 59950 Geschäftsführer Johann-Peter Hartmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksp0bcACgkQSuF5XhWr2nhdwQCggzxIUz8N7ZlRLWWklTqJBnPO BSoAniiOqs2JXyh4iNwRtp9FiGRIy/16 =q9+2 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
