Re: General kernel question about waiting for events

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Wed, 2009-12-02 at 00:24 +0000, Alan Cox wrote: 
> > In that case, wrapped in different packages, it always ends with
> > following loop:
> > 
> > while( event == false )
> > schedule();
> 
> No. If it were to do that then real time processes could spin eating the
> CPU forever.
> 
> There is a difference between rescheduling and sleeping for an event.
> Sleeping for an event (ie on a waitqueue) means that you will not be
> woken until the wait queue is woken (or certain other things like signals
> if interruptible). Rescheduling gives the CPU to someone else if anyone
> wants it.
> 
> In short the different task states that are set are the important bit to
> look at to understand this further.
Thanks you very much!

I already begin to investigate in that area, but your answer sums
everything up, sorry for silly (as I expected) question.

So, current task state is set to TASK_UNINTERRUPTIBLE or
TASK_INTERRUPTIBLE which differ in signal delivery (that I understood,
the TASK_INTERRUPTIBLE will break the wait when signal is received) but
both mean that current task is removed from scheduler pool until it is
woken up, or in case of schedule_timeout() also after the timeout
expires.
Also wait_event_interruptible_timeout does check the condition to avoid
useless sleeps, but if another thread or interrupt handler want to wake
it up, it not only sets that condition (it is optional at all) but
actually wakes the task up using literally wake_up() or related
functions.

Best regards,
Maxim Levitsky