Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-21 Thread Doug Evans
On Tue, Jan 21, 2014 at 8:21 PM, Mark H Weaver wrote: > Tom Tromey writes: > >>> "Ludovic" == Ludovic Courtès writes: >> >> Ludovic> I guess this is another limitation of Guile’s current signal >> handling >> Ludovic> strategy, and something we should fix. >> >> FWIW I think it would be suf

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-21 Thread Mark H Weaver
Tom Tromey writes: >> "Ludovic" == Ludovic Courtès writes: > > Ludovic> I guess this is another limitation of Guile’s current signal handling > Ludovic> strategy, and something we should fix. > > FWIW I think it would be sufficient for gdb if scm_system_async_mark, or > something like it, co

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-15 Thread Ludovic Courtès
Tom Tromey skribis: >> "Ludovic" == Ludovic Courtès writes: > > Ludovic> I guess this is another limitation of Guile’s current signal handling > Ludovic> strategy, and something we should fix. > > FWIW I think it would be sufficient for gdb if scm_system_async_mark, or > something like it, c

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-14 Thread Tom Tromey
> "Ludovic" == Ludovic Courtès writes: Ludovic> I guess this is another limitation of Guile’s current signal handling Ludovic> strategy, and something we should fix. FWIW I think it would be sufficient for gdb if scm_system_async_mark, or something like it, could be invoked from a signal han

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-07 Thread Tom Tromey
> "Ludovic" == Ludovic Courtès writes: Ludovic> I guess this is another limitation of Guile’s current signal handling Ludovic> strategy, and something we should fix. I think it seems reasonable for Guile itself, but yeah, it makes it harder to integrate into gdb. I was pleasantly surprised

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-07 Thread Ludovic Courtès
Tom Tromey skribis: > Ludovic> Would it work, upon SIGINT, to do something like: > Ludovic> (system-async-mark (lambda () > Ludovic>(throw 'system-error ... EINTR))) > Ludovic> That would eventually raise an exception in Scheme code. > > According to the Guile docs one m

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-07 Thread Tom Tromey
> "Ludovic" == Ludovic Courtès writes: Ludovic> So do I get it right that it’s GDB that does signal(SIGINT, ...), and Ludovic> its handler just calls PyOS_InterruptOccurred (or so) if Python code Ludovic> happens to be running? Yeah. >> One approach for multiple extension languages might be

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-07 Thread Ludovic Courtès
Tom Tromey skribis: >> "Ludovic" == Ludovic Courtès writes: > > Ludovic> I’m not sure I understand the problem. > > Ludovic> What are extension languages typically expected to do when the ‘quit’ > Ludovic> flag is set? > > The basic idea is that if some extension code is running, then C-c ou

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2014-01-06 Thread Tom Tromey
> "Ludovic" == Ludovic Courtès writes: Ludovic> I’m not sure I understand the problem. Ludovic> What are extension languages typically expected to do when the ‘quit’ Ludovic> flag is set? The basic idea is that if some extension code is running, then C-c ought to interrupt that code in the

Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

2013-12-24 Thread Doug Evans
[+ guile-user, in case they have any thoughts on Guile SIGINT handling] On Mon, Dec 23, 2013 at 1:57 PM, Tom Tromey wrote: >> "Doug" == Doug Evans writes: > > Doug> +void > Doug> +clear_quit_flag (void) > Doug> +{ > Doug> + int i; > Doug> + const struct extension_language_defn *extlang; >