[FOR REVIEW, PATCH 0/2] do_wait() cleanups.

[FOR REVIEW, PATCH 0/2] do_wait() cleanups.

[Oleg Nesterov]

While this is not strictly necessary, I'd like to also cleanup do_wait/etc
before changing ptrace internals. Just because this code is still hardly
readable, imho. And we are going to complicate this code a little bit.

This trivial change nearly killed me. I didn't expect I will spent all
night doing this!!!

The patch is not tested, I am sending it for the early review, because
before I do the next changes I'd like to know your opinion: do you agree
with this patch "in general" ?

If yes, I'll send the next trivial cleanups on top:

	- factor out getrusage() code

	- factor out infop filling

	- simplify retval/notask_error interaction

	- perhaps some small simplifications in do_wait's callers

Naming. I agree in advance with any changes you suggest, and this is
another reason I am sending it early.



Also. This is completely off-topic wrt ptrace cleanups, but if we
change do_wait() now perhaps it makes sense to optimize do_wait()
in PIDTYPE_PID case. In this case we do not need to scan the lists,
we can inspect the task directly. This change should be simple, but
it will increase .text. Do you think it makes sense?


I do not plan any other cleanups before changing ptrace internals.

Oleg.

Re: [FOR REVIEW, PATCH 0/2] do_wait() cleanups.

[Roland McGrath]

> Also. This is completely off-topic wrt ptrace cleanups, but if we
> change do_wait() now perhaps it makes sense to optimize do_wait()
> in PIDTYPE_PID case. In this case we do not need to scan the lists,
> we can inspect the task directly. This change should be simple, but
> it will increase .text. Do you think it makes sense?

Yes, I think that's a worthwhile optimization in its own right.  In waitpid
calls using an explicit PID, it will be a huge help for both applications
with many other children and for applications with many threads (when the
waitpid caller does not happen to be the fork caller).  It looks like it
would be simple and cheap enough.

I doubt this would need much restructuring of the code (just a
short-circuit path that calls wait_consider_task from do_wait after
checking !task_detached(p) && !task_ptrace(p) && __WNOTHREAD ?
p->real_parent == current : same_thread_group(,p->real_parent)).
If that's true, then we can do this later after settling these
cleanups and ptrace stuff, perhaps along with the wakeup-avoidance
hack that never got finished.  That stuff is really just pure optimization
not inherently apropos to anything else.


Thanks,
Roland