Re: [RFA] lin-lwp.c change to avoid obscure hanging

["Paul N. Hilfinger" <hilfingr@otisco.mckusick.com>]

> > 3. The user executes the commands
> >      delete
> >      thread B
> >      continue

> This isn't really a sensable thing to do anyway.
> Probably the user is imagining that this will cause
> thread B to be treated in some way specially (eg. 
> resumed before the others), but it will not
> (or at least it should not).

Oh, I'm SO glad you brought this up, because it is a point that could stand 
clarification.  

Q1. Consider the following sequence (user input preceded by prompts)

	  (gdb) run
	  ...
	  Breakpoint 1, philosopher ...
	  (gdb) info thread
          * 7 Thread 5126 (runnable) ...
	  ...
	  (gdb) thread 6   # I.e., Some thread other than the current one
	  (gdb) signal 1

     What is supposed to happen?  What DOES happen (on Linux) is that thread 7 
     receives SIGHUP.

Q2. Now consider what happens when one thread is sent an asynchronous SIGHUP
    (on Linux, there are kernel threads, and you can address a signal to
    a specific thread from the command line with the kill command).

          (gdb) run
	  ...
	  Program received signal SIGHUP, Hangup.
	  ...
	  (gdb) info thread
          * 7 Thread 5126 (runnable) ...
	  ...
	  (gdb) thread 6
	  (gdb) cont

     Here what happens is that thread *6* receives SIGHUP.

Q3.  Finally, we have

          (gdb) run
	  ...
	  Program received signal SIGHUP, Hangup.
	  ...
	  (gdb) info thread
          * 7 Thread 5126 (runnable) ...
	  ...
	  (gdb) thread 6
	  (gdb) signal 1

     Again, thread 6 receives SIGHUP.

Question: How much of this, if any, is intentional?  What should happen in
these cases?

Paul Hilfinger