> 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 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
