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

[Michael Snyder <msnyder at redhat dot com>]

"Paul N. Hilfinger" wrote:
> 
> > > 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.

There are actually three predicates here:
  - what is supposed to happen
  - what does happen
  - what is expected to happen.

What you describe above (thread 7 receives the signal)
is what is expected to happen.

GDB's thread model is lacking in several areas, and one of them
is the ability to resume a thread other than the one that stopped.
Since we have not designed an interface for doing this in general, 
we don't do it at all (even on platforms such as Linux where it
might be possible).  So the thread that resumes is always the
thread that stopped, no matter what thread you switch to in the
mean time.


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

Ugh!  Well, that's a bug.  
That's not what is "supposed" or "expected" to happen.

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

No, that's a bug too.


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

Q1 is intentional, Q2 and Q3 are not.

Michael