Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote:
> >These are threading information packets.  They are completely optional,
> >and I believe that they are of an appropriate nature for the
> >environments which support it; such systems generally:
> 
> Optional or not, it needs to be reliable.  You need to be able to run a 
> test cases 1000 times and have it pass 1000 times.

I really do not see what is unreliable here.  They're still ACKed...

> >  a) Should have no trouble implementing asynchronous responses.
> >	It needed about fifteen lines of code changed in gdbserver,
> >	so most Unix-alikes should be fine.  VxWorks could certainly
> >	do it as well.
> >
> >  b) Desire the least-intrusive possible thread debugging.
> >	These aren't niche events; in a multithreaded application,
> >	thread creation and deletion can happen very frequently, and
> >	with a large number of running threads.  I've heard a lot
> >	of complaints about how much our intrusive thread debugging
> >	harasses scheduler priorities.
> >
> >I'd rather ditch the notifications entirely than stop other threads;
> >I'll keep the notification code out of the FSF tree until we can figure
> >out a generally acceptable way to pass asynchronous status
> >notifications back to the client.  I really don't see the problem with
> >my suggestion, though.
> 
> Hmm, I think you're trying to combine several disjoint features into a 
> single mechanism.
> 
> Feature #1 is notify GDB of [remote] thread create/delete events.
> Feature #2 is allow some [remote] threads to continue running while 
> others (just current?) have stopped.
> 
> >Heck, if I can work out a way to do it safely, I intend to do
> >one-thread-stopped-only SVR4 shared library support also.  I've heard
> >that starting apache2 (multithreaded, and with all modules as DSOs)
> >takes several minutes instead of the second or two that it takes
> >without GDB attached.
> 
> Yes, feature #2 above.

I don't know how generally useful feature #2 is (although it's
certainly useful internally).  The question becomes whether core
GDB needs to know that some threads are still running, or if we can
get by without that.  Informing core GDB of this fact is beyond me.

I'd appreciate any comments on the Hs issue; I'm just going to leave
the notification packets out of the first submission of this code,
since they are controversial.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer