This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: async event loop and ^C


J.T. Conklin writes:
 > >>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes:
 > >> My WDB backend's to_wait function polls the target for WDB events
 > >> (context exit, exceptions, breakpoints hit, etc.).  But quit_flag is
 > >> checked in the polling loop. If it is set, a context suspend command
 > >> is sent to the target.  However, with the new async event loop, ^C
 > >> handling is deferred until the event loop is entered so quit_flag is
 > >> never set.
 > >> 
 > 
 > Elena> If immediate_quit is set, the handling of ^C is not deferred to the
 > Elena> event loop. Can you maybe set this variable?
 > 
 > I don't think so.  
 > 
 > If immediate_quit is set, handle_sigint() calls async_request_quit(),
 > which calls quit(), which calls return_to_toplevel().  to_wait never
 > has a chance to send the suspend command.
 >

I see, yes.
The immediate work around for this is to use gdb w/o the event loop.
You can invoke it with --noasync or change (in main.c) this:

/* Whether this is the async version or not.  The async version is
   invoked on the command line with the -nw --async options.  In this
   version, the usual command_loop is substituted by and event loop which
   processes UI events asynchronously. */
int event_loop_p = 1;


To:

/* Whether this is the async version or not.  The async version is
   invoked on the command line with the -nw --async options.  In this
   version, the usual command_loop is substituted by and event loop which
   processes UI events asynchronously. */
int event_loop_p = 0;


Looking at request_quit(), the test on immediate_quit was failing in
your case, with the old code, and the only effect was to set
quit_flag, right?
Maybe we can set quit_flag in hande_sigint() if immediate_quit is not set.
But that would not be enough, unless we don't mark the signal handler either.
Or we could have a second level of 'quit urgency' beside immeditate_quit,
and, for this case, just set the quit_flag. 
The remaining ^C cases would still go through the event loop.

Elena

 >         --jtc
 > 
 > -- 
 > J.T. Conklin
 > RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]