[Bug gdb/14236] Cannot continue in background with target-async after interrupting

["xdje42 at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14236

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #3 from Doug Evans <xdje42 at gmail dot com> ---
Now that I have a patch that works (from a user's perspective) the way I want
it to, I've found three testcases that assume an implicit "&":

gdb.base/
async-shell.exp
dprintf-non-stop.exp
interrupt-noterm.exp

Another way to look at this, obviously, is to not expect the "interrupt"
command to wait, and have a separate "wait" command.  I think we want a
separate wait command, regardless. However, that doesn't mean the current
design of interrupt isn't broken.
Alas, adding "&" to "interrupt", and changing the default behaviour to wait,
*could* break existing code.

Another way to do is to add a "-w" command to interrupt to mean "wait".
All that would mean is that one could type

interrupt -a -w

instead of

interrupt -a
wait -a

The latter, however, opens up a source of confusion if the user types

interrupt -a
wait

With my user's hat on I'd expect that when I see the gdb prompt after doing
"interrupt -a" all threads are in fact stopped.  I'm working on the above
alternatives, but for now I'm going to see what the community thinks of adding
& to "interrupt".

-- 
You are receiving this mail because:
You are on the CC list for the bug.