Hello All,
I second Adam Lee.
here is some more detail for reference.
http://www.linuxjournal.com/article/6916
http://www.linuxjournal.com/article/6916
Regards
Sanjeev Sharma
Sanjeev Sharma
On Thu, Jan 22, 2015 at 2:13 PM, Adam Lee <adam8157@xxxxxxxxx> wrote:
This is a very good question. My thoughts(maybe not right):On Thu, Jan 22, 2015 at 12:55:12PM +0530, Er Krishna wrote:
> Hi All,
>
> Pls help me here to understand the following scenario:
>
> As we know, we cant sleep inside interrupt handler. But what is the reason for
> it?
>
> If I put sleep inside the handler code handler, handler code will not complete
> and none of the process on that particular processor will ever will execute. So
> it will be kind of deadlock. But what if the system is having multiple
> processors ? Is it safe here to sleep ? If not what is the reason ?
1, can't sleep inside a interrupt handler, it's kind of by design but
not a hardware limit.
2, the scheduler and IRQ system need to be re-designed to support sleep
inside interrupt handlers, like to support the IRQ handler as a schedule
unit, handle IRQ handlers by a certain kernel thread other than in
processes' context. Otherwise handler code won't complete and the
process context(like those holding locks) will deadlock, this answered
your question, still not safe.
3, what if the sleep inside interrupt handlers are supported as "thought
2"? The scheduler will be far too complicated, system will become very
unstable because IRQs are so not real time then.
--
Adam Lee
http://adam8157.info
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies