Reentrancy problem forking children with the PHP client
mikael at synd.info
Tue Aug 28 05:24:05 UTC 2007
Since you actually fork the process there should be no possibility of
sharing memory between children. And since the connection is established
after the fork no sockets are shared, in which case you would probably
get data corruption errors instead of a whole object being swapped.
Also, the client doesn't use any globals and works fine under ZTS (the
thread safe PHP build).
If you have a short script that reproduces the problem, I'd be glad to
give it a try and see if I can hunt down the problem.
Kenner Stross wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.danga.com/pipermail/memcached/attachments/20070828/2b27bc44/signature.pgp
More information about the memcached