Re: Stand resume() on its head

[Michael Snyder <msnyder at redhat dot com>]

Andrew Cagney wrote:
> 
> Hello,
> 
> 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, ...
> 
> I think, in the end, GDB will need to do something like this any way
> (how else is GDB going to handle suspended threads?) so might as well
> start earlier rather than later :-)
> 
> (thinking out loud)
> Andrew

That's probably a good idea.  Difficult to know how else to handle
large numbers of threads, if we eventually have some sort of 
suspend/resume functionality.

If we do this, though, we should pay attention to efficiency, 
since it's fairly important that all threads be activated 
as close to simultaneously as possible.