Why does schedule_timeout() take a signed long as an argument and then check
for possible negative values? Wouldn't it be better to just take an unsigned
long as argument, thus eliminating all dumb checks in the code?
Also, couldn't MAX_SCHEDULE_TIMEOUT be defined zero to make checking for it
faster (actually I did find five calls to schedule_timeout() using zero
timeout, but couldn't they just use plain schedule() instead?)?
Another issue I found concerns setting current task state to TASK_RUNNING
after calling schedule_timeout(). This seems to be done in many parts of the
kernel, though Kernel-API documentations found from kernelnewbies.org seem
to claim that task state is guaranteed to be TASK_RUNNING after
schedule_timeout() returns. Is the documentation faulty or does the kernel
have obsoleted code?
Lahti Oy wrote:
>
> Why does schedule_timeout() take a signed long as an argument and then check
> for possible negative values? Wouldn't it be better to just take an unsigned
> long as argument, thus eliminating all dumb checks in the code?
Because someone may do:
schedule_timeout(when_i_want_to_wake - jiffies);
and if the current time happens to be _after_ when_i_want_to_wake,
we want schedule_timeout to cope with that and do the right thing.
> Another issue I found concerns setting current task state to TASK_RUNNING
> after calling schedule_timeout(). This seems to be done in many parts of the
> kernel, though Kernel-API documentations found from kernelnewbies.org seem
> to claim that task state is guaranteed to be TASK_RUNNING after
> schedule_timeout() returns. Is the documentation faulty or does the kernel
> have obsoleted code?
The documentation is correct.