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

Le 16 décembre 2009 16:54, Antony Dovgal tony@daylessday.org a écrit :

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