On Wednesday 14 March 2007 20:53, M Harris wrote:
> On Wednesday 14 March 2007 23:29, Randall R Schulz wrote:
> > > I was just trying to kill some processes on a Win2003 system
> > > today and had to wait for the kernel to finish some tasks before
> > > it would die.
> >
> > That can happen on Linux, too. Try to kill a process in a 'D' wait
> > state. It's not possible. Extended duration of a D wait does imply
> > a bug (usually in a disk or file system driver), but it happens.
>
>       Whether a user at root level can kill a process is not necessarily a
> test of how well preemptive multitasking has been implimented.

The problem I'm referring to is unrelated to access control privileges. 
The kernel simply will not allow a signal to interrupt a process that 
is waiting at or below priority 0 (not to be confused with nice level 
0). This is because the integrity of the kernel's shared data 
structures depends on such waits being uninterruptable. They're used 
only for things like disk I/O (hence the signifier 'D' in ps output), 
but bugs or dropped interrupts can cause them to persist indefinitely. 
When that happens, the user-level process cannot be terminated no 
matter what you do (short of poking kernel memory in some extremely 
well-crafted manner, I suppose).


> However, if the kernel (or other ring zero processes) receive more
> time slice than other processes on the system then there may be a
> problem... and the M$ kernel (and other ring zero processes) are
> notorious for not playing well in the preemptive sandbox.... which
> means, well, it ain't truly preemptive---  I will admit that they
> have made huge strides from the early windoze days... but they are no
> match for the linux kernel... no way.

In both cases we're talking about bugs interfering with normal process 
scheduling, not the design of the operating system kernels, both of 
which (Linux and Windows at least from NT onward) are genuinely 
preemptive, time-sliced, interrupt-driven and _non-_cooperatively 
scheduled.


> M Harris     <><


Randall Schulz
-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to