Re: Stand resume() on its head

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Nov 05, 2002 at 03:28:19PM -0500, 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 :-)

I like it, roughly speaking.  I've got a couple of other thoughts and
some questions:
 - What do you mean by suspended threads?

 - User interface for this?  We could use this opportunity to fix
and clarify passing signals.  A command to show pending signals
per-thread for the next resume; a command to set them.

 - Why would we want to step a particular thread in a resume?  If we
want to single-step a particular thread then it seems to me that we
want to do it independently of resuming other threads.

 - Is there a useful way to combine this with a mechanism to report
more than one event from a wait?  More than one thread stopping with a
signal, for instance.  That'll also need interface changes, but we need
the interface changes anyway: see the failing test for hitting a
watchpoint and a breakpoint at the same time, in annota2.exp.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer