On Tue, Feb 23, 2010 at 2:09 PM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: > Hi Greg, > >> Instead there is an intermediary context that I don't think you've >> taken into account. >> >> I believe timers are also invoked in this intermediary context. ie. >> When a timer invokes a function you can't trust the process / task >> structures to relate to your original userspace app. > > I think what you're referring to with intermediate context is work > that is deferred for later so that the userspace app doesn't have to > wait. > > Like for example when a write() happens, this doesn't have to > necessarily go all the way till the disk immediately, instead its > written to the page cache first and the kernel returns to userspace > immediately. The process of writing from memory to disk is done later > by something like pdflush or kjournald which are actually kernel > threads executing in Process context. Is this what you mean by > intermediate context? > > -Joel > Sounds right. I've gotten out of my depth, so I should quit digging before the dirt collapses around me. But I have to ask now that I've gone this far. When a function is called via a timer firing, what is the process context? I know why back in my UNIX days the process / task structures were effectively undefined. (ie. I think that had valid content, but they did not necessarily relate to the userspace app that was active with the timer was set.) With linux today, is there a specific process context (ie. kernel thread) associated with executing functions triggered by timers firing off? Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
