Re: Stand resume() on its head

[Michael Snyder <msnyder at redhat dot com>]

Daniel Jacobowitz wrote:
> 
> 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?

Just what you think -- give the user the ability to say
"this thread should not resume when the others do."

>  - User interface for this? 

Important, and yet to be worked out.  Wanna start the discussion?

> 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.

Hmmmm!

>  - 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.

Currently that's true.  I can't think of a circumstance where it
wouldn't be true, but I haven't thought real hard about it.

>  - 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.

In a single-processor system, I don't think that can happen.
It's bogus that Linux-gdb lets it appear to happen (at least internally).
But yeah, it can sure happen in a multi-processor environment.
Have any thoughts to share about that interface?

Michael