(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]
