The scan itself i don't mind. It is the rescan that bothers
me. That is bother as in almost, but not quite, an itch.
"Awful" is perhaps an overstatement. I agree the space
should be sparse enough to make rescans infrequent and i
have trouble imagining what these systems must be like that
the rescanning actually loops interminably. Increasing
PID_MAX should make the pid space sparse enough to make the
problem implausible.
I was just responding to the frequent discussions of
"get_pid hang" and when i looked at get_pid said "yuck".
One of the bigger problems i have with the scan is the very
idea that there are pids that cannot be used because they
are still referenced but don't exist. That sounds lax to
me. I can understand the advantage of it. The only place
it seems to impact is get_pid. Keeping the task structs
around would mean coping with them in several other places.
It does occur to me that there could be some advantage to
having these terminated session, thread and process group
leaders show up in ps.
Well, i've put in my $0.02 plus interest.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/