> > 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?
The interrupt handler's execution time will definitely defer the execution of the process, but I think it does not steal the process's time slice (the time_slice field not subtracted).
> > 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
My understanding is, the ISR is in different context from the process because of the definition of term *context*. In my opinion, to say two code pieces running in the same context means that two pieces of code has some logical relationship to meet a common objective. That's why I said *context* is a higher-level logical concept. It's not a concept defined in the level of hardware or code implementation, but instead in the level of logical. I think, by its definition, it makes no sense to say an ISR share context with the process interrupted by it because an ISR just randomly interrupts a process, with no logical relationship. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
