lkml.org 
[lkml]   [1999]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: schedule_timeout() semantics/usage?
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.039 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site