Hi folks, 

The up and coming kernel (2.4.20, I believe?) and the next glibc (2.3.1)
both bring some drastic changes to linux threads.  The current gdb thread
debugging code will not handle them as is.

This is a smallish change that I propose as a preliminary step;
it'll get things partly working in the new world, without breaking
them in the old.

Here's the rationalle.

In the old/current model, when one thread gets a signal (such as TRAP), 
we (gdb) have to call kill (SIGSTOP, pid) for every other thread
(excepting the event thread), and then do a waitpid on each of them.

In the new model, when one thread gets a signal, we only have to 
send kill(SIGSTOP, pid) to _one_ thread, and the kernel will then
propagate the signal to all of them (_including_ the one that has
already stopped with eg. SIGTRAP).  We must still do a waitpid on
each and every thread -- however, that now _includes_ the one that
stopped in the first place (and which we've already done one waitpid on).

I know, you're thinking "wasn't this supposed to get simpler?"

The minimal change I propose below is as follows:
When we send kill(SIGSTOP) to all the threads, we now include
the event thread, where previously we had made him a special case.
That way, whether in the new model or the old one, we can now do
a waitpid on every thread including the event thread.

What do you think?

Michael