I don't like the idea of reusing recent pids at all.
The current repeated scanning is awful. I've been mulling this over
in my mind for awhile now and i've had two thoughts.
If we insist on scanning the task list we should at least
reap multiple pids. Have an array of free pids managed
inside get_pid() that it pulls from until it runs out at which
point it would do the scan to refill the array + 1 for
immediate use.
Here is my better suggestion.
Dont destroy the task_struct of exited tasks that
are session, thread group or process group leaders
until last group member exits. Give them a status
so that they don't show up in /proc. Heck go ahead
and mark them as zombies if you want though i'd
rather another status.
Preserved the pid number sort order of the
prev_task/next_task list. It looks to me like this
is already the case.
get_pid() continues to preserve next_safe.
Also preserve a task_struct *last_safe which would be
set to the last pid created. release_task() whould update
it to p->prev_task if last_safe == p.
get_pid() would use *last_safe->next_task to walk
until it found a gap >= next_safe. (looping if it
hits PID_MAX)
So by adding a couple of bits of logic in wait() and keeping
around a relatively small number of task_structs for exited
processes we can eliminate the scan alltogether.
Defering the release_task() for group leaders eliminates the
need for rescanning and opens the possiblity of using
find_task_by_pid() instead of scanning as someone recently
suggested.
What have i missed? This seems much simpler than the other
aproaches i've seen proposed. It should also be much more
deterministic in behavior.
-- ________________________________________________________________ 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/