On 13:52 Tue 18 Nov , nidhi mittal wrote: > as far as i know > 1:set_current_state (TASK_INTERRUPTIBLE) > 2:schedule() The process didn't meet a condition and is guided its way to sleep. An interrupt b/w lines 1&2 means nothing to the scheduler in context with the current task as the task hasn't yet started waiting on the interrupt. You can say it's on it's way to sleep. The process can't stop and claim "My interrupt! I don't want to sleep". This is because the scheduler can't understand what "My interrupt!" means. In other words the scheduler doesn't know the current task is waiting on a interrupt until the task appears on a concerned wait_queue for the interrupt. In this case the current task appears on the wait_queue only after a call to schedule() where, if TASK_INTERRUPTIBLE the process is put to sleep, off the rq and on to the wait_queue. Ideally the task is eligible to run because the interrupt has occured. But the scheduler says to the task "sorry, I dunno of any marriage b/w you and the specific interrupt. You are on your way to sleep." You see the scheduler is doing all it needs to do. Thanks for the link. Trash my previous reply and am sorry for that. - Rahul > statement 1 only changes the state variable in task_struct doesnt put the > process to sleep > so after statement 1 the process is in a state where its state is > task_interruptible but its not out of runqueue. > > then when scahedule is called > it takes decison like this. > if the process state is TASK_INTERRUPTIBLE it put the process to sleep takes > it out of runqueue. > but if its state is TASK_RUNNIG and schedule is called its not put out of > runqueue only scheduled out for some time. > these are correct statements according to this article > http://www.linuxjournal.com/article/8144 > > > > so please now consider my ques ... -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
