Reentrancy problem forking children with the PHP client

Kenner Stross kenner at
Tue Aug 28 00:32:38 UTC 2007

There appears to be a re-entrancy issue with the PHP client.  Here's a
brief recap of my situation:

I have a daemon process that is written in php (and is thus called like
this: "php -e myDaemon -- -paramOne -paramTwo &").  Once it is launched,
it follows standard daemon coding practices to set itself up as a
detached session leader and wait for something to do.  Once there is
something to do, it will fork some children to do the work.  Looks like

myDaemon (the parent, which forks three times in this example)
	myDaemon (child 1)
	myDaemon (child 2)
	myDaemon (child 3)

The memcache client is not instantiated until the children have forked,
so that each child can have a memcache client that is separate from and
unrelated to the other children.  However, it appears that they are all
still intertwined at some deeper level, apparently as a result of having
forked out of the same php process space (I guess).

The symptoms are this: At various random points, a memcache "get" for
object1 (whose type is class1) will return object2 (whose type is
class2).  In other words, it is returning the wrong objects.  To me,
this sure looks like a reentrancy problem, where one child is being
swapped in by the processor at JUST THE RIGHT MOMENT to pick up the
OTHER OBJECT from the OTHER CHILD that was just swapped out.

The confirmation that this is the problem is that when I set a limit
such that the parent can never fork more than one child, the problem
goes away.  Handled that way, memcache always returns the correct

Has anybody had similar experiences?  I'd love to hear what others may
know about this issue and/or the architecture of the php client
vis-a-vis forking.

Kenner Stross

More information about the memcached mailing list