Le 16 décembre 2009 16:54, Antony Dovgal <[email protected]> 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
