RE: Does HEAD support non-stop with 'gdbserver --multi' on Linux?

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Tuesday, May 12, 2009 11:58 AM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: Does HEAD support non-stop with 'gdbserver 
> --multi' on Linux?
> 
> On Tuesday 12 May 2009 16:21:48, Marc Khouzam wrote:
> > I saw that with non-stop, when doing native linux debugging, there
> > is a conscious decision to trigger thread events as soon as possible
> > (from a comment of linux-nat.c:linux_handle_extended_wait()).
> 
> At the time I added that to linux-nat.c it seemed like a
> good idea, but in hindsight, I'm not sure it was.  This has
> the potential to generate *a lot* of create/exit event pairs
> for no apparent good reason --- consider a program that spawns
> a lot of short lived worker threads.  Against remote
> targets, this would be even worse, due to extra slowness.

Yes, this was bothering me too, from the frontend point-of-view.

> 
> > However, this does not happen when using gdbserver.
> > 
> > Is this something that is not ready yet, or a bug, or ... ?
> 
> This is a remote protocol issue.  The remote protocol does not have
> any support for new thread notifications.  GDB only learns about
> new threads when they report an event (say one hits a breakpoints),
> or when the thread list is explicitly requested.
> 
> OOC, how does the eclipse/java debugger behave on such
> scenario?  Are short lived threads added/removed from the GUI
> even if they don't report a stop event?

Good question.
I just ran some test to figure this out.  It turns out that
threads are added and removed from the GUI without any stop
event.  Furthermore, was creating and destroying a thread
every 200 milisec, and the UI was flickering to show each 
and every change!

But that may not be the way we want to go... I'm not sure.
This behavior could be a user preference.
Right now, in DSF-GDB for GDB7.0, any =thread-created/exited
event will immediately be shown to the user.
I was postponing addressing this risk until someone
brought this up as a problem...

Currently, I'm leaning towards a periodic refresh scheme.
Say every half second, the list of threads would be refreshed
if needed.  But I have to think about this further.
Such a scheme could be used in GDB also.

Marc