Re: Stand resume() on its head

[Andrew Cagney <ac131313 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.
Here, I think aiming for a slow working solution will be better than 
trying for a fast broken one.

Once the model is working, someone can tune it so it can be scaled to 
handle that 10 000 threads.

Andrew