RE: non-stop and current thread exiting

[Vladimir Prus <vladimir@codesourcery.com>]

Marc Khouzam wrote:

> Hi,
> 
> so we all agree that a) is no good.
> 
> b) and c) are good.
> The advantage of b), as you point out, is that the user
> can see which thread was previously selected.  However,
> since GDB will no longer be changing threads automatically,
> a frontend will already know which thread was previously
> selected.
> 
> So, my first impression is that c) is actually better
> since it keeps 'info thread' looking the same.  Having b) report
> a thread as (exited) will require the frontend to add extra
> intelligence to parse that.
> 
> This may not be true from a user's point-of-view
> where she/he may not remember the previously selected thread.
> But I haven't figured out if the user would really care.

What I was thinking if that if you select a thread, and continue it,
and the thread exits, it would be more user-friendly to gray this
thread, add "(exited)" and then retire it next time we stop. The
other alternative is either message box "thread is exited", which is
obtrusive, or "passive popup", or message in status bar, which, on
the contrary, can be easily ignored. 

You are right that some frontend changes will be required -- but they
are required anyway to show the "running" state of the thread, so
seems the extra change to show "exited" state does not add much
complexity.

> In the case of b) or c) one point that is important for the
> a frontend is how GDB will react to prohibited commands
> when no thread is selected?  Will a prohibited command
> cause an ^error or maybe an empty ^done, or something else?

With (b), you always have some thread selected. When it is actually
exited thread, I'd say ^error is the best way. If you send a command
and get empty ^done, while you expect some data in the response, it's
not very good, I think.

- Volodya