Re: behaviour when only running thread exits (non-stop mode)

[Doug Evans <dje at google dot com>]

On Tue, Mar 24, 2009 at 11:33 AM, Doug Evans <dje@google.com> wrote:
> What's the intended behaviour, as far as what the user sees, when the
> only running thread exits in non-stop mode?
> [where this thread is not the main thread, and there can be any number
> of other threads, they're just not running - e.g. the user is
> singlestepping one thread in non-stop mode]
>
> Currently gdb is hanging because thread exits are ignored (in the
> TARGET_WAITKIND_IGNORE sense), and with no thread running even ^c's
> passed to the target (via pass_signal) won't get the command prompt
> back.
>
> Non-stop mode is not supposed to automagically switch threads on the
> user, so it seems like gdb shouldn't randomly switch to another
> thread.
> I'm blocked on deciding how to break out of the event loop so that the
> user can at least get the command prompt back. Throwing an error in
> linux_nat_filter_event (which is where this situation is first
> detected) feels wrong but maybe it's ok.
>

Sorry for the followup.  "break out of the event loop" is poorly worded.  Blech.
What I meant was of course how does one tell the event loop, in this
particular case, that execution has stopped so gdb should take the
terminal back (and get the command prompt back)?
Calling error() works, modulo needing to update restore_current_thread
to first check that the recorded current thread still exists.  Is
there a better way?