Hi!
> > > Doesn't matter. killall could have been scanning the process table directly
> > > and it still would not have worked and for the same reason described
> > > elsewhere.
> >
> > If he got D-state than yes. But if he tried to stop forkbomb by
> > killall, it is user error. [Maybe he did not try to stop forkbomb, I
> > don't know.]
>
> It is hard to tell. In the past, I've seen killall fail several times,
> usually because it can't get enough CPU time to complete a scan
> before
This is exactly what I was talking about. killall just can't be
trusted.
> the situation changes (more processes created, processes going into/out of
> D-state rapidly...). To me, it seems that (at least for root) it would be
> usefull if killall changed its' scheduling priority high enough (real time?)
> that it would be able to send the signal to all processes it finds BEFORE
> its context is switched out...
And if you have two cpus? No, sorry, that's too ugly. Forget killall.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:11 EST