"Douglas A. Tutty" <dtu...@vianet.ca> writes: > On Wed, Jun 24, 2009 at 10:05:20PM -0400, Scott Gifford wrote: >> "Douglas A. Tutty" <dtu...@vianet.ca> 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 periodically. 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 occurs. ----Scott. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
