[PATCH] Collect processes in batches

[Roland McGrath]

> The patch works like this: collect all waitable tracees, store them
> in a linked list, then traverse it and act on each tracee.
> Rinse, repeat.

I understand.

> This might work too. You are proposing to collect a waitable tracee,
> decide what to do with it, remember the action you want to do on it
> and store the tracee in a linked list, go back and collect next waitable
> tracee. When there is no more tracees, perform remembered actions.

Correct.

> Looks more complex because you need to store a bit of data (action you
> want to perform) with each remembered tracee, but it might work.

Obviously it can work, there is no "might" about it.  I don't think it's
more complex than your plan.  Either you have to record the signal you want
to pass to ptrace, or you have to record the wait result.

> In my algorithm, I never ever try to delete a tcb which is in the middle
> in the middle of the list of remembered tracees because I always process
> the list from the head. Deletion at the head is trivial.

I understand.  However, instead you have a different kludge that IMHO is
far more confusing.

> I decided to deal with this problem simply by stashing out the pid
> and wait status in remembered_pid and remembered_status variables,
> process and flush the list I accumulated so far, then process
> another "list" of tracees which consists of only one tracee: the one
> whose status I saved in (remembered_pid, remembered_status) tuple.

I'm not entirely sure I understand how this works in all cases.  But it
certainly seems like a strange kludge to me.  Both the magic single global
store and the linear search on the pending list seem quite ugly.

> In my code this is not necessary since it always processes tracees
> at the head of the collected list, thus any deletion will also happen
> at the head.

But instead you have the kludgey second linear search.
Storing a state bit is obviously better than that.

> But it can be done your way too.

I'd like to see an implementation along the lines I described.
IMHO it is far easier to follow such code than what you have done.
I think there are other (vague) advantages in how the control flow
scales when there are many threads reporting, too.


Thanks,
Roland