Re: Stand resume() on its head

[Andrew Cagney <ac131313@redhat.com>]

> On Nov 5,  3:28pm, Andrew Cagney wrote:
> 
> 
>> There have now been several discussion threads that lead to the 
>> conclusion that
>> 
>> 	target->resume (ptid_t, int, enum target_signal)
>> 
>> needs changing.  At present the suggestion is to add a parameter to 
>> indicate schedule locking and similar operations.
>> 
>> I'd like to propose a different approach.  Instead of passing to 
>> resume() what to do, have resume() iterate over all the threads asking 
>> each what it should do - suspend, step, run, signal, ...
> 
> 
> Sounds reasonable.  (In fact, it seems a whole lot more workable than
> the other approach.)

Yep, figure out the worst case and solve that - then discover that the 
solution is better than the other partial approaches :-)

Andrew