Re: Why can't we sleep in an ISR?

["pradeep singh" <2500.pradeep@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On 5/15/07, Dong Feng <middle.fengdong@gmail.com> wrote:
>
> >
> > good enough, but i have a query regarding this then.
> > On a 8K kernel stack system, doesn't interrupts share the stack
> associated
> > with the current process which was interrupted?
>
> Yes, I think so.
>
> Yes it does.
> > Doesn't interrupt steals the CPU slice time allocated to the running
> process
> > to run?
>
> I don't think so but I am not sure.


Aliter, i think so.How
 can an interrupt's execution time go unaccounted then?
I guess it does not, only the current processes running time is accounted
for.
Thoughts?

> Doesn't it run in current process's context ?
> >
>
> No. I think the concept of process context is a higher-level logical
> concept. Though the interrupt share stack with the interrupted
> process, in my opinion it logically does not share the context with
> the process.


Yes, you are right as i can infer. thats why ISRs are special kernel
control paths.
But the poster asked, why can't we make ISRs to share context with the
interrupted process if
it not holding any locks? This is rather a desing issues IMO rather
than imlementation, isnt it?


I guess even if it is possible, it would over complicate the handler code.
Better trying to keep it simple i guess. Please CMIIW

[snip]
>
> But I do not see the exact relationship between your specific queries
> and the original question. Could you elaborate?


My query here was related to your previous reply.Just wanted to pit some doubts
as raised by the orirignal poster.That's it.

Thank you
~psr




-- 
play the game

[-- Attachment #2: Type: text/html, Size: 3042 bytes --]