Hi, Thanks for your quick answer. I can well imagine the trouble one can run into with spinlocks (e.g. on a 2-CPU machine task A holds spinlock x, gets scheduled away as a result of an interrupt, task B and C get scheduled on the 2 CPUs, both try to get spinlock x and consequently spin forever on their respective CPU -> the machine 'freezes'). I.e. my initial question why you can't sleep in an interrupt handler is answered by this scenario. However, just out of interest, could you explain me the problems that could result from the task being on arbitrary wait_queues? regards Martin Jan Hudec wrote: > > 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> -- Supercomputing System AG email: maletinsky@scs.ch Martin Maletinsky phone: +41 (0)1 445 16 05 Technoparkstrasse 1 fax: +41 (0)1 445 16 10 CH-8005 Zurich -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
