John Levon wrote:
>
> On Wed, 6 Sep 2000, George Anzinger wrote:
>
> > John Levon wrote:
> > >
> > > Am I right ? against test8pre1
> > >
> > > Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
> > > schedule_timeout() ? What will happen ?
> > >
> > Well, first the "timeout" call will return immediately. Next, when the
> > time out actually happens, if the task is not TASK_RUNNING (i.e. it is
> > waiting for some other thing) it will wake_up. So the sleep is lost and
> > it is possible to have a false wake up (could even wake up a zombie).
> > If the actual timeout happens while the task is TASK_RUNNING it is
> > ignored.
> >
> > George
> >
>
> 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 not quite correct. The call to timeout WILL return
immediately, however, the timeout code will clean up the timer, so there
should be no worry there. It is a bug in that the sleep does not happen
as expected. I saw at least one place where there were comments about
it not working.. and he did not set the state. For what its worth I
think the schedule_timeout() should be changed to __schedule_timeout()
and two new time out calls be used {un}interruptible_sleep_on_timeout(),
these calls to do the set up of state. In fact the interruptible
version already exists. Of course things like select would have to use
__schedule_timeout() as they are waiting for any of several events.
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
