On Nov 1, 2006, at 16:58, Fei Liu wrote:
There also seems to be a second problem: Child processes are
exiting without something being delivered where it's supposed to
go. I can't really tell if this is what you mean, or what the
details are, without more information.
I'll get more information on this question, this confuses me as
well and I need to get an answer.
We are able to identify that the exit(0) call takes roughly 100ms
to be picked up by waitpid inside POE::Kernel. By changing exit(0) to
close($fh);
return;
we are able to make POE::Kernel pick up child exit status
immediately within 5 ms. We suspect that exit(0) is taking too long
to actually exit. I don't know why that's the case, perhaps it's an
expensive system call, too many I/O synchronization..?
The 100ms delay is probably caused by the way POE handles SIGCHLD.
It polls for processes using a non-blocking waitpid() call rather
than registering a signal handler. We can't rely on everyone to use
modern perl, unfortunately, or this restriction would be easy to
remove. Furthermore, SIGCHLD isn't portable within Windows versions
of Perl, so the waitpid() poll remains the most reliable method for
child process reaping.
Unfortunately we can't waitpid() poll 1000 times per second. We
generally only do it 10 times. Thus your 100ms delay.
The reason that POE has to wait for a child to terminate is that
the response object is being communicated through Storable
serialization. This is very inefficient and I don't know why it's
done that way and if it can be improved. Only when POE::Kernel
reaps a child server process, it can ask the Wheel::Run Parent
session to pick up the response.
At this point, we are hitting a wall again and it seems we have
squeezed as much performance as possible out of the entire POE &
CONDA marriage. My timing shows that a request is now served
usually within 50 ms instead of 100+ ms before the exit(0) change.
There are alternatives. For example, the act of receiving a response
object from the child process should be sufficient to trigger other
actions:
1. Child sends response to parent.
2. Parent receives response, and immediately does something with it.
Right now you're doing:
1. Child sends response to parent.
2. Parent receives response, and buffers it.
3. 100ms later, waitpid() triggers the parent to process the response.
--
Rocco Caputo - [EMAIL PROTECTED]
