In <[🔎] 20090625143028.GA7284@blitz.hooton>, Douglas A. Tutty wrote: >On Wed, Jun 24, 2009 at 10:05:20PM -0400, Scott Gifford wrote: >> "Douglas A. Tutty" <dtutty@vianet.ca> writes: >> > 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. >> 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. No, it really doesn't. At the kernel level, it is possible to add a function to a list of functions to be run when another process exits. The wait/waitpid calls without a timeout basically do that and then put the waiting process to sleep. Once the does process exits, the kernel runs through the list of registered functions and eventually calls one that wakes up the sleeping process. True asynchronous / event-based programming is ultimately more efficient that polling solutions not because the polling is done elsewhere, but because the polling is eliminated entirely. (It's actually rare to see much of an end-to-end improvement in throughput by moving the polling around.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.