Re: schedule_timeout() semantics/usage?

David Hinds (dhinds@varesearch.com)
Wed, 20 Oct 1999 15:06:58 -0700

On Wed, Oct 20, 1999 at 11:38:25PM +0200, Andrea Arcangeli wrote:
> On Wed, 20 Oct 1999, David Hinds wrote:
>
> > do {
> > current->state = TASK_INTERRUPTIBLE;
> > timeout = schedule_timeout(timeout);
> > } while (timeout);
> > current->state = TASK_RUNNING;
>
> Yes, that will work fine and it's the right thing to do, except the fact
> you don't care about signals in the above fragment and so you should use
> TASK_UNINTERRUPTIBLE instead (it will avoid some not necessary
> schedule()).

Ok... then this raises a few questions:

- I'm not clear on the semantics of current->state. In various places
in the kernel, it is set to TASK_INTERRUPTIBLE, then may or may not
be set back to TASK_RUNNING. Is not setting it back to TASK_RUNNING
a bug? What are the consequences? Should it be set inside the loop
as above, or should I set it once, before entering the loop?

- Something like 95% of callers of schedule_timeout() ignore the
return value. Many seem to expect it to not return early: it is
used for timed delays in many drivers. Are these all bugs?

- Are signals the only reason for early-exit? If so, then if I use
TASK_UNINTERRUPTIBLE, does that guarantee that the return value is
always zero, so the loop is superfluous? Why do virtually all
drivers use TASK_INTERRUPTIBLE, when it seems that UNINTERRUPTIBLE
has the more appropriate semantics?

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/