Re: Stand resume() on its head

Andrew Cagney
2002-11-05T23:14:13Z

> 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