Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313@cygnus.com>]

> On Thu, May 02, 2002 at 12:39:37PM -0400, Andrew Cagney wrote:
> 
>> I'm fairly sure that the archives have plenty of info on the ``O'' 
>> packet and why/how it should be replaced.  One thread is ``gdb/remote - 
>> I/O''.
> 
> 
> Ah, I've found the thread.  I see that there was a rough consensus
> (among just about everyone but J.T. Conklin, who I believe was remote
> maintainer at the time?) about the disadvantages of asynchronous

Joint.  I think the consensus was that the advantages of a more robust 
mechanism (some will laugh at the very suggestion that the GDB protocol 
is even vaguely robust :-) outway the disadvantages of having the 
protocol synchronous.

> replies.  However, I'd like to add another point of view.

At one level I agree with you completly, unfortunatly the remote 
protocol, as it stands, just don't work that way :-(  The ``O'' packet 
while ``a good idea at the time'' (sarcasm) just doesn't cut it when it 
comes to providing something that is reliable.

> 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.

>   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.

enjoy,
Andrew