* Matthew Wilcox <matthew@xxxxxx> wrote: > In some circumstances, you want to wait for an event to happen. let's > assume that it's a hardware event, so you can't just add a notifier of > some kind, you have to poll. Here's an example: > > On Wed, Sep 03, 2008 at 03:57:13PM -0700, Stephen Hemminger wrote: > > return -ETIMEDOUT; > > - udelay(10); > > + if (signal_pending(current)) > > + return -EINTR; > > + schedule(); > > If there's no other task ready to run, schedule() could return in much > less than 10 microseconds (actually, it could return in much less than > 10 microseconds even if another task does run, but let's ignore that case). > > If schedule() returned whether or not it had scheduled another task, we > could do something like: > > if (!schedule()) > udelay(10); hm, i'm not really sure - this really just seems to be a higher prio variant of yield() combined with some weird code. Do we really want to promote such arguably broken behavior? If there's any chance of any polling to take a material amount of CPU time it should be event driven to begin with. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
