(With some reordering) On Friday 26 December 2003 14:29, Eli Billauer wrote: > After all, it's not the process that volunteers > to kill itself. It's the system that kills it.
Yes, but we talk about a code section within the kernel. This means that the code has more control on "the rules of the game" than normal user-space code. > This little discussion still hasn't answered my first, and most > interesting question: How can a process be running, and yet not > killable. In kernel space many code section have to acquire locks to protect access to shared data. The kernel programmer can use: - Locks that can break with signals. So he must deal with the case the lock is broken. - Locks that cannot break with signals. The later type is easier for the programmer (no need to handle special cases), but the process is not interruptible during this period. Normally, the programmer should use this type of locking only when there is no alternative and the protected code fragment is bounded in execution time. > But if context is switched every now and then, I would expect the > OS to check for signals. Yes, but in your case there was no context switch because: > spin_lock_irqsave(&state->card->lock, flags); > i810_update_ptr(state); <-- This is where it was caught! The spin_lock*(...) family of locks is doing busy waiting and so no context switch happens. If you'll check the definition of this specific call, you'll see that it disable even the 2.6 kernel preemption. Hope this explanation clears it out. What is still interesting is to know if this case of non-preemptible locking was due to programmer laziness or was inherent to the task this code was doing. Bye, -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron We don't do windows... -------------------------------------------------------------------------- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]