Re: Non-stop multi-threaded debugging

[Vladimir Prus <ghost@cs.msu.su>]

Pawel Piech wrote:

> Nick Roberts wrote:
>>  >                                           ... A -thread-select on an
>>  > ID of a process followed by an -exec-continue would resume an entire
>>  > process, while a -thread-select of a thread's ID followed by a
>>  > continue
>>  > would resume only that thread.  This could also be applied to all
>>  > other commands that need to operate on a process, such as
>>  > -thread-list-ids, -break-insert, etc.
>>
>> This would change the current behaviour of these commands.  If a new
>> command is undesirable then perhaps optional parameters could be used:
>>
>>      -exec-continue [ -p THREAD-ID/PROCESS-ID ]
>>      -exec-interrupt [ -p THREAD-ID/PROCESS-ID ]
>>
>> It appears that -break-insert already has such an option for threads.
>>
>>   
>  From Eclipse's point of view it actually doesn't make much difference
> whether -thread-select or -p option is used to specify the thread.
> 
> That said, I would argue that adding the non-stop debugging feature
> changes the behavior of the entire system, so it could be expected that
> some commands will behave somewhat differently as they relate to this
> new feature.  Actually, with non-stop debugging feature turned off, and
> without attaching to multiple processes, these commands would still
> behave exactly as they do now.

Given the choice between:

1. Changing the behaviour of the existing command, and adding new one
that behaves like existing one, and

2. Adding new command

I think adding new command (or option to existing command), is a smaller change.
So yes, -exec-continue -t <xxx> might be a better choice.

- Volodya