Messages in this thread |  | | Date | Thu, 07 Sep 2000 09:14:10 -0700 | From | George Anzinger <> | Subject | Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE |
| |
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/
|  |