This was fine, but I needed to do some statistical analysis of connections and, in particular needed to be able to raise alarm events if particular nodes persistently didn't connect at all. To this end, each handler wrote little IPC files to say how they got on with the connection that they were given to handle. I then needed to have the main server periodically hoover up these files and do appropriate things. I thought 'I know, I'll put a call to the monitoring routine in the loop':while accept fork a handler
This would have been fine except in the most important case of failure (no-one connects at all) the loop would block on the accept and the check routine never ran so no alarm would be raised.while accept fork a handler check any handler results
And this worked. But it only ever handled one connection and then just appeared to block on the accept, ignoring any attempted connections. If I removed the call to fork the monitor everything worked fine. Odd.fork a monitor to check results while accept fork a handler
It occurred to me that it looked as though the 'fork a handler' fork was getting confused about which process was the right one to continue in after the fork. Almost like it was trying to resume in the most-recently-forked 'monitor' fork (which doesn't have the socket open) instead of the fork it came from. So I moved the monitor fork like this:fork myself into background fork a monitor while accept fork a handler
And this works exactly as I would expect. What I'm curious about is, was the behaviour on the former configuration exactly what a well-informed person should expect or was it buggy aberrant behaviour?fork a monitor fork myself into background while accept fork a handler
In reply to Mangled Forks by mungohill
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |