David Woodhouse wrote:
>
> moz@compsoc.man.ac.uk said:
> > So it seems to be a bug at least in terms of timing. Unfortunately I
> > only got about 4 replies to the patches that touched 20+ drivers. I
> > suppose I should just hassle maintainers until they fix it or tell me
> > where I've gone wrong ...
>
> Actually, I was quite happy calling schedule_timeout in the flash drivers
> without changing current->state. I'm waiting to something to happen, and
> just to be considerate, I'm asking to be put to sleep for the 'expected'
> amount of time for whatever's happening. If there's other stuff on the run
> queue, it won't return immediately, will it?
It most likely will return immediately. The only case it would not is
if, while you were running:
A tick happened and some other task in the run queue then had a higher
count of remaining ticks, or
Something event happened to cause the system to want to run some other
task (i.e. need_resched is set)
In no case will the system wait for anything related to the time you
send to schedule_timeout() (which, I think should be called something
like xxx_sleep().
>If there isn't other stuff on
> the run queue, I'll just busy wait till the flash chip's finished.
No you will _almost always_ busy wait.
>
> Otherwise, it would be TASK_UNINTERRUPTIBLE.
UNINTERRUPTIBLE refers to being open to signals. A task waiting
UNINTERRUPTIBLE can not be killed (or otherwise signaled) while it is
waiting. Signals that come in against the task are just queued until
the task allows them to be recognized (by exiting to user land or
explicitly calling signal delivery (which very few code paths do)). By
waiting INTERRUPTIBLE, the system will wake_up() the task when a signal
is posted against it. The task still has to respond to it in one of the
above two ways.
For what it is worth, I think the system needs a "deliver_signal()"
function just for this. I think that this function should have:
a.) A "task being killed" call back function, so callers can clean up if
the call is not going to return, but instead is killing the task. This
would allow drivers to test for being killed as opposed to just being
handed some other relatively unimportant signal and to clean up their
act if needed.
b.) An indication (return value) that tells if a user handler was
called.
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST