Re: Canceling a long running gdb/mi command

[Tom Tromey <tom@tromey.com>]

Dmitry> I was wrong, it works, but one might need to send several
Dmitry> SIGINTs. In my case, the first exception thrown by quit() was
Dmitry> caught and ignored in cp-support.c replace_typedefs(), and the
Dmitry> gdb/mi command continued running. The second one was caught 
Dmitry> and handled in cp-support.c inspect_type() which made a slow
Dmitry> -var_list_children command to complete.

Catching and ignoring like that seems bad.  IMO only non-QUIT exceptions
should be caught in this way, at least in most places.

I see a lot of violations of this idea though -- grep says 282.  So that
is not good.  Though on reflection, not all of these are really
incorrect, because the 'try' block may not end up calling QUIT.

Fixing this seems like a bit of a pain.  Probably some of those catches
really should handle QUIT as well.  Also it seems like some kind of
region-based QUIT suppression has to be done, because there are parts of
gdb that can't really be QUIT from (e.g., the DWARF reader is basically
unprepared for this).

I wonder whether varobj can really handle interruption.
That code is pretty hard to work on... anyway it would be interesting to
see a stack trace from your scenario.

Dmitry> Is it by design and clients should send SIGINTs repeatedly?

No.

Dmitry> Do I understand correctly, that it is safe to send a SIGINT when
Dmitry> no gdb/mi command is running? Meaning it won't terminate
Dmitry> gdb. I've tried and it works, but maybe I was lucky.

Yes, I think this should be fine.  However, if the inferior is running,
I think it may cause an inferior stop.

Tom