George Anzinger wrote:
>
> In looking over the kernel for preemption hazards I found the following:
>
> The following function is from select.c. Can someone help me to
> understand why do_pollfd() is being called with the task state set to
> TASK_INTERRUPTIBLE?
Yes.
> do_pollfd() calls the driver poll routine. Is it
> expected that the driver might in some way call schedule() and put the
> current task to sleep?
Yes.
> Or would this be a big NO-NO.
A small no.
A driver could sleep, but then it must set current->state back to
TASK_RUNNING before sleeping, and that should be very rare, otherwise
poll()/select() will busy-loop instead of yielding the cpu to other
processes.
> I think the state
> should be set just prior to the schedule_timeout() call. Would this
> impair some functionality?
Yes, you would see lock-ups ;-)
See linux/Documentation/DocBook/mousedrivers.tmpl
If you want to support preemption, then the minimum is:
* we can't preempt if the current thread owns a spinlock
* we can't preempt if current->state != TASK_RUNNING
* ??
-- Manfred- 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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:09 EST