Messages in this thread | | | Date | Wed, 20 Oct 1999 15:06:58 -0700 | From | David Hinds <> | Subject | Re: 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/
| |