Hi... On Mon, Feb 9, 2009 at 2:57 PM, <sudheer.divaka...@wipro.com> wrote: > Hi All, > Please look at the following code from the article Sleeping in the Kernel > > http://www.linuxjournal.com/node/8144/print > > 1 set_current_state(TASK_INTERRUPTIBLE); > 2 spin_lock(&list_lock); > 3 if(list_empty(&list_head)) { > 4 spin_unlock(&list_lock); > 5 schedule(); > 6 spin_lock(&list_lock); > 7 } > 8 set_current_state(TASK_RUNNING); > 9 > 10 /* Rest of the code ... */ > 11 spin_unlock(&list_lock); > > > Is there any chance for the process getting scheduled out of the run-queue > at Line# 2 (say the scheduler runs because of timer interrupt)??
Let's see... we see no preemption disabling, no interrupt disabling...so yes, I think rescheduling could happen there. >If so, the > process won't be scheduled again. Right? yep, unless this code path receive signal (the process which this code path runs on behalf of), or if other code path sends try_to_wake_up() >If so, what is the best solution > for preventing that? prevent? well, to me that's expected to happen. regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
