On Wed, Jul 02, 2003 at 09:04:02AM +0200, Martin Maletinsky wrote:
> However can't you consider the interrupt handler as running in the
> context of the task A, that was incidentially running when the
> interrupt occurred (the interrupt handler uses the stack of task A, as
> Jan wrote). So wouldn't it conceptually be conceivable to put the
> interrupt handler to sleep by saving the current CPU state (register
> contents) with task A, putting task A asleep, and resume processing of
> the interrupt once task A is rescheduled by the scheduler?
>
> Of course this could be considered 'unfair' with respect to task A, in
> that the interrupt has no relation to task A besides the fact that
> they happend to be on the same CPU at the same time. But I am
> interested in learning if there is any fundamental reason against
> sleeping in an interrupt handler.
There are bigger problems. The process is in an arbitrary state when
interrupt is invoked. So it might hold arbitrary spinlocks. It might
be on arbitrary wait_queues. Possibly other funny things might happen.
These either disallow sleeping or could interact badly with the
interrupt trying to sleep.
> Jan Hudec wrote:
> > On Tue, Jul 01, 2003 at 06:22:29PM +0200, Martin Maletinsky wrote:
> > > [...]
> >
> > Sleeping is implemented using scheduler. Scheduler only schedules tasks
> > (design decision to keep it simple). So you need a task context to sleep
> > in. Interrupt is not tied to a process (and uses stack of whichever
> > happens to be scheduled) so it can't use the context because it does not
> > have to be in a sane state.
^^^^^^^^^^
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
