Re: OT: launching jobs in a combined serial parallel way
"Douglas A. Tutty" <firstname.lastname@example.org> writes:
> On Wed, Jun 24, 2009 at 10:05:20PM -0400, Scott Gifford wrote:
>> "Douglas A. Tutty" <email@example.com> writes:
>> > On Mon, Jun 22, 2009 at 08:17:44PM -0400, Kamaraju S Kusumanchi wrote:
>> > While you may think its terribly inefficient, it isn't really. A fancy
>> > "wait" function is just polling anyway, you're just making it overt.
>> Just to clarify, wait(2) and the shell wait builtin do not poll, they
>> instruct the kernel to put the process to sleep until a child process
>> finishes, then wake it up and return from the wait call. Because of
>> that they are very efficient. Still, if the programs in question are
>> doing a great deal of work, the extra work required by polling will
>> not be very significant in comparison.
> Isn't that just passing the polling on to the kernel? At some level,
> some process has to see if a pid exists, if not, wait a period, then
> check again.
I don't believe so. I believe that the parent process is suspended
completely, then when the child process exits, the kernel checks to
see if the parent process is currently waiting, then wakes it up. So
the wakeup is initiated when the child process exits, not checked
Perhaps a kernel hacker can confirm this, but looking in
$KERNEL_SRC/kernel/exit.c, sys_exit() calls do_exit() which calls
exit_notify(); that calls do_notify_parent() from signal.c, which
re-activates the parent process.
It's much like a blocking read(2) or select(2) is put to sleep by the
kernel, to be woken up again when the condition it's waiting for