non-stop and current thread exiting

non-stop and current thread exiting

[Pedro Alves]

Hi all,

Non-stop has currently one issue to resolve that I'd like
your input on.

With all stop, no command is allowed while the inferior is running.
In sync mode, well, GDB isn't listenning to commands, in async mode,
only a few commands are allowed, I think help, interrupt, dir, pwd,
not much else.  These are all commands safe to use.

Imagine the case where you're debugging a multi-threaded app.  There
are 3 threads including the main thread.
Thread 2 is selected.   You issue continue, that thread exits, but
GDB doesn't give the user the control then, the inferior is kept running.
Finally, when some other thread hits a breakpoint GDB switches the
user thread to it automatically.  Hence, there was never a situation
where the selected thread has already exited, on which case the user
could issue commands to a dead thread.

Now, enter non-stop.  With non-stop, however, we'll want to be
able to say for example "info threads" at any time (or -thread-info,
in MI).

Take this example:

 (gdb)l
 75          volatile int *myp = (volatile int *) &args[my_number];
 76
 77          /* Don't run forever.  Run just short of it :)  */
 78          while (*myp > 0)
 79            {
 80              (*myp) ++;
 81              usleep (1);  /* Loop increment.  */
 82              //      printf ("thread_function1: %d\n", *myp);
 83              //      fflush (stdout);
 84            }
 (gdb)l
 85
 86          pthread_exit(NULL);
 87      }

 (gdb) b 80
 Breakpoint 1 at 0x80485f0: file threads.c, line 80.
 (gdb) r

 Starting program: /home/pedro/gdb/tests/threads32
 [Thread debugging using libthread_db enabled]
 [New Thread 0xf7d5bb90 (LWP 8506)]
 [New Thread 0xf755ab90 (LWP 8507)]
 [Switching to Thread 0xf755ab90 (LWP 8507)]

 Breakpoint 1, thread_function1 (arg=0x1) at threads.c:80
 80              (*myp) ++;

 (gdb) n&
 (gdb) 81                usleep (1);  /* Loop increment.  */

Now, let's let the selected thread exit.

 p *myp=0
 $1 = 0
 (gdb) c&
 Continuing.
 (gdb) [Thread 0xf755ab90 (LWP 8507) exited]

At this point, which should be the selected thread,
and what should "info threads" show?

GDB isn't currently prepared for this situation,
so with the last non-stop series I posted, several 
commands issued at this point trigger internal
assertions, because the current thread doesn't exist
in the thread list.

I see three possibilities to solve issues like these.

a) Have GDB switch to an arbitrary thread when the
  current thread is gone.

b) Leave the currently selected dead thread in the thread
  list, tag it as dead.  Prohibit most commands but "thread"
  and "info threads" in this situation.  Get rid of the dead
  thread as soon as the user/frontend switches to another
  thread.

 (gdb) info threads
 * 3 Thread 0xf755ab90 (LWP 8507)  (exited)
   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

Notice the "(exited)" mark.

 (gdb) print a
 The selected thread is no longer available.  See `help thread'
 to change selected thread.

Switching threads:

 (gdb) thread 2
 [Switching to thread 2 (Thread 0xf7ddfb90 (LWP 10771))] (running)

Ah, it's gone now:

 (gdb) info threads
 * 2 Thread 0xf7ddfb90 (LWP 10771)  (running)
   1 Thread 0xf7de06b0 (LWP 10766)  (running)


c) Allow deleting the current thread anyway, and have it not
   listed in the thread list.  Do some internal magic, to point
   the current thread at some "already exited" special thread.
   Prohibit most commands but "thread" and "info threads" in
   this situation.  Show something like this or similar
   in "info threads"

 (gdb) info threads
   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

   No selected thread.

I like b) or c) because I prefer that GDB doesn't switch
threads on me automatically.  Having 'call ExitThread (1)<enter>'
apply to the wrong thread, because GDB decided to switch threads
on my back between `)' and `<enter>', is a race I'd like to avoid.

b) has the disadvantage that code that iterates over threads may
  have to take care of not doing things to dead threads.  I don't
  think there are many places.
  It has the advantage that the user can still see some info
  on which thread was last selected.

c) has the advantage that code that iterates over threads, can still
   rely on a thread being ptid(-1) to mean it's dead.  Easier to
   spot a bug.  We can perhaps still show to the user which thread
   was selected by storing that info in some global:

   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

   The selected thread was 3, but it has exited.  Please 
   change threads.


We had a small internal discussion, and at the time there was
concensus that b) would be the best option.

What do you think?  Do you see other options, or problems
with b) ?

Marc, could you share with us your thoughts, in the
perspective of a non-stop frontend developer ?

-- 
Pedro Alves

Re: non-stop and current thread exiting

[Joel Brobecker]

> We had a small internal discussion, and at the time there was
> concensus that b) would be the best option.

That's the alternative that I would choose too.

-- 
Joel

RE: non-stop and current thread exiting

[Marc Khouzam]

Hi,

so we all agree that a) is no good.

b) and c) are good.  
The advantage of b), as you point out, is that the user
can see which thread was previously selected.  However,
since GDB will no longer be changing threads automatically,
a frontend will already know which thread was previously
selected.

So, my first impression is that c) is actually better
since it keeps 'info thread' looking the same.  Having b) report
a thread as (exited) will require the frontend to add extra
intelligence to parse that.

This may not be true from a user's point-of-view
where she/he may not remember the previously selected thread.
But I haven't figured out if the user would really care.

In the case of b) or c) one point that is important for the 
a frontend is how GDB will react to prohibited commands
when no thread is selected?  Will a prohibited command
cause an ^error or maybe an empty ^done, or something else?

At this time, I don't have a clear picture of how the frontend
will behave in those cases so I'm not sure what is best yet...

So, in short I vote for c), but b) would be acceptable too.

Marc 

-----Original Message-----
From: Pedro Alves [mailto:pedro@codesourcery.com]
Sent: Tue 6/3/2008 5:53 PM
To: gdb@sourceware.org
Cc: Marc Khouzam
Subject: non-stop and current thread exiting
 
Hi all,

Non-stop has currently one issue to resolve that I'd like
your input on.

With all stop, no command is allowed while the inferior is running.
In sync mode, well, GDB isn't listenning to commands, in async mode,
only a few commands are allowed, I think help, interrupt, dir, pwd,
not much else.  These are all commands safe to use.

Imagine the case where you're debugging a multi-threaded app.  There
are 3 threads including the main thread.
Thread 2 is selected.   You issue continue, that thread exits, but
GDB doesn't give the user the control then, the inferior is kept running.
Finally, when some other thread hits a breakpoint GDB switches the
user thread to it automatically.  Hence, there was never a situation
where the selected thread has already exited, on which case the user
could issue commands to a dead thread.

Now, enter non-stop.  With non-stop, however, we'll want to be
able to say for example "info threads" at any time (or -thread-info,
in MI).

Take this example:

 (gdb)l
 75          volatile int *myp = (volatile int *) &args[my_number];
 76
 77          /* Don't run forever.  Run just short of it :)  */
 78          while (*myp > 0)
 79            {
 80              (*myp) ++;
 81              usleep (1);  /* Loop increment.  */
 82              //      printf ("thread_function1: %d\n", *myp);
 83              //      fflush (stdout);
 84            }
 (gdb)l
 85
 86          pthread_exit(NULL);
 87      }

 (gdb) b 80
 Breakpoint 1 at 0x80485f0: file threads.c, line 80.
 (gdb) r

 Starting program: /home/pedro/gdb/tests/threads32
 [Thread debugging using libthread_db enabled]
 [New Thread 0xf7d5bb90 (LWP 8506)]
 [New Thread 0xf755ab90 (LWP 8507)]
 [Switching to Thread 0xf755ab90 (LWP 8507)]

 Breakpoint 1, thread_function1 (arg=0x1) at threads.c:80
 80              (*myp) ++;

 (gdb) n&
 (gdb) 81                usleep (1);  /* Loop increment.  */

Now, let's let the selected thread exit.

 p *myp=0
 $1 = 0
 (gdb) c&
 Continuing.
 (gdb) [Thread 0xf755ab90 (LWP 8507) exited]

At this point, which should be the selected thread,
and what should "info threads" show?

GDB isn't currently prepared for this situation,
so with the last non-stop series I posted, several 
commands issued at this point trigger internal
assertions, because the current thread doesn't exist
in the thread list.

I see three possibilities to solve issues like these.

a) Have GDB switch to an arbitrary thread when the
  current thread is gone.

b) Leave the currently selected dead thread in the thread
  list, tag it as dead.  Prohibit most commands but "thread"
  and "info threads" in this situation.  Get rid of the dead
  thread as soon as the user/frontend switches to another
  thread.

 (gdb) info threads
 * 3 Thread 0xf755ab90 (LWP 8507)  (exited)
   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

Notice the "(exited)" mark.

 (gdb) print a
 The selected thread is no longer available.  See `help thread'
 to change selected thread.

Switching threads:

 (gdb) thread 2
 [Switching to thread 2 (Thread 0xf7ddfb90 (LWP 10771))] (running)

Ah, it's gone now:

 (gdb) info threads
 * 2 Thread 0xf7ddfb90 (LWP 10771)  (running)
   1 Thread 0xf7de06b0 (LWP 10766)  (running)


c) Allow deleting the current thread anyway, and have it not
   listed in the thread list.  Do some internal magic, to point
   the current thread at some "already exited" special thread.
   Prohibit most commands but "thread" and "info threads" in
   this situation.  Show something like this or similar
   in "info threads"

 (gdb) info threads
   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

   No selected thread.

I like b) or c) because I prefer that GDB doesn't switch
threads on me automatically.  Having 'call ExitThread (1)<enter>'
apply to the wrong thread, because GDB decided to switch threads
on my back between `)' and `<enter>', is a race I'd like to avoid.

b) has the disadvantage that code that iterates over threads may
  have to take care of not doing things to dead threads.  I don't
  think there are many places.
  It has the advantage that the user can still see some info
  on which thread was last selected.

c) has the advantage that code that iterates over threads, can still
   rely on a thread being ptid(-1) to mean it's dead.  Easier to
   spot a bug.  We can perhaps still show to the user which thread
   was selected by storing that info in some global:

   2 Thread 0xf7d5bb90 (LWP 8506)  (running)
   1 Thread 0xf7d5c6b0 (LWP 8503)  (running)

   The selected thread was 3, but it has exited.  Please 
   change threads.


We had a small internal discussion, and at the time there was
concensus that b) would be the best option.

What do you think?  Do you see other options, or problems
with b) ?

Marc, could you share with us your thoughts, in the
perspective of a non-stop frontend developer ?

-- 
Pedro Alves

RE: non-stop and current thread exiting

[Vladimir Prus]

Marc Khouzam wrote:

> Hi,
> 
> so we all agree that a) is no good.
> 
> b) and c) are good.
> The advantage of b), as you point out, is that the user
> can see which thread was previously selected.  However,
> since GDB will no longer be changing threads automatically,
> a frontend will already know which thread was previously
> selected.
> 
> So, my first impression is that c) is actually better
> since it keeps 'info thread' looking the same.  Having b) report
> a thread as (exited) will require the frontend to add extra
> intelligence to parse that.
> 
> This may not be true from a user's point-of-view
> where she/he may not remember the previously selected thread.
> But I haven't figured out if the user would really care.

What I was thinking if that if you select a thread, and continue it,
and the thread exits, it would be more user-friendly to gray this
thread, add "(exited)" and then retire it next time we stop. The
other alternative is either message box "thread is exited", which is
obtrusive, or "passive popup", or message in status bar, which, on
the contrary, can be easily ignored. 

You are right that some frontend changes will be required -- but they
are required anyway to show the "running" state of the thread, so
seems the extra change to show "exited" state does not add much
complexity.

> In the case of b) or c) one point that is important for the
> a frontend is how GDB will react to prohibited commands
> when no thread is selected?  Will a prohibited command
> cause an ^error or maybe an empty ^done, or something else?

With (b), you always have some thread selected. When it is actually
exited thread, I'd say ^error is the best way. If you send a command
and get empty ^done, while you expect some data in the response, it's
not very good, I think.

- Volodya

Re: non-stop and current thread exiting

[Pawel Piech]

Thanks Marc to point it out to me, I did indeed miss it.
I'm also think that option c) is optimal.  I think option b) is fine as 
well, as long as -thread-list-ids returns the list of live threads only, 
even if info threads show the exited threads. 

Cheers,
Pawel

Marc Khouzam wrote:
> Hi,
>
> so we all agree that a) is no good.
>
> b) and c) are good.  
> The advantage of b), as you point out, is that the user
> can see which thread was previously selected.  However,
> since GDB will no longer be changing threads automatically,
> a frontend will already know which thread was previously
> selected.
>
> So, my first impression is that c) is actually better
> since it keeps 'info thread' looking the same.  Having b) report
> a thread as (exited) will require the frontend to add extra
> intelligence to parse that.
>
> This may not be true from a user's point-of-view
> where she/he may not remember the previously selected thread.
> But I haven't figured out if the user would really care.
>
> In the case of b) or c) one point that is important for the 
> a frontend is how GDB will react to prohibited commands
> when no thread is selected?  Will a prohibited command
> cause an ^error or maybe an empty ^done, or something else?
>
> At this time, I don't have a clear picture of how the frontend
> will behave in those cases so I'm not sure what is best yet...
>
> So, in short I vote for c), but b) would be acceptable too.
>
> Marc 
>
> -----Original Message-----
> From: Pedro Alves [mailto:pedro@codesourcery.com]
> Sent: Tue 6/3/2008 5:53 PM
> To: gdb@sourceware.org
> Cc: Marc Khouzam
> Subject: non-stop and current thread exiting
>  
> Hi all,
>
> Non-stop has currently one issue to resolve that I'd like
> your input on.
>
> With all stop, no command is allowed while the inferior is running.
> In sync mode, well, GDB isn't listenning to commands, in async mode,
> only a few commands are allowed, I think help, interrupt, dir, pwd,
> not much else.  These are all commands safe to use.
>
> Imagine the case where you're debugging a multi-threaded app.  There
> are 3 threads including the main thread.
> Thread 2 is selected.   You issue continue, that thread exits, but
> GDB doesn't give the user the control then, the inferior is kept running.
> Finally, when some other thread hits a breakpoint GDB switches the
> user thread to it automatically.  Hence, there was never a situation
> where the selected thread has already exited, on which case the user
> could issue commands to a dead thread.
>
> Now, enter non-stop.  With non-stop, however, we'll want to be
> able to say for example "info threads" at any time (or -thread-info,
> in MI).
>
> Take this example:
>
>  (gdb)l
>  75          volatile int *myp = (volatile int *) &args[my_number];
>  76
>  77          /* Don't run forever.  Run just short of it :)  */
>  78          while (*myp > 0)
>  79            {
>  80              (*myp) ++;
>  81              usleep (1);  /* Loop increment.  */
>  82              //      printf ("thread_function1: %d\n", *myp);
>  83              //      fflush (stdout);
>  84            }
>  (gdb)l
>  85
>  86          pthread_exit(NULL);
>  87      }
>
>  (gdb) b 80
>  Breakpoint 1 at 0x80485f0: file threads.c, line 80.
>  (gdb) r
>
>  Starting program: /home/pedro/gdb/tests/threads32
>  [Thread debugging using libthread_db enabled]
>  [New Thread 0xf7d5bb90 (LWP 8506)]
>  [New Thread 0xf755ab90 (LWP 8507)]
>  [Switching to Thread 0xf755ab90 (LWP 8507)]
>
>  Breakpoint 1, thread_function1 (arg=0x1) at threads.c:80
>  80              (*myp) ++;
>
>  (gdb) n&
>  (gdb) 81                usleep (1);  /* Loop increment.  */
>
> Now, let's let the selected thread exit.
>
>  p *myp=0
>  $1 = 0
>  (gdb) c&
>  Continuing.
>  (gdb) [Thread 0xf755ab90 (LWP 8507) exited]
>
> At this point, which should be the selected thread,
> and what should "info threads" show?
>
> GDB isn't currently prepared for this situation,
> so with the last non-stop series I posted, several 
> commands issued at this point trigger internal
> assertions, because the current thread doesn't exist
> in the thread list.
>
> I see three possibilities to solve issues like these.
>
> a) Have GDB switch to an arbitrary thread when the
>   current thread is gone.
>
> b) Leave the currently selected dead thread in the thread
>   list, tag it as dead.  Prohibit most commands but "thread"
>   and "info threads" in this situation.  Get rid of the dead
>   thread as soon as the user/frontend switches to another
>   thread.
>
>  (gdb) info threads
>  * 3 Thread 0xf755ab90 (LWP 8507)  (exited)
>    2 Thread 0xf7d5bb90 (LWP 8506)  (running)
>    1 Thread 0xf7d5c6b0 (LWP 8503)  (running)
>
> Notice the "(exited)" mark.
>
>  (gdb) print a
>  The selected thread is no longer available.  See `help thread'
>  to change selected thread.
>
> Switching threads:
>
>  (gdb) thread 2
>  [Switching to thread 2 (Thread 0xf7ddfb90 (LWP 10771))] (running)
>
> Ah, it's gone now:
>
>  (gdb) info threads
>  * 2 Thread 0xf7ddfb90 (LWP 10771)  (running)
>    1 Thread 0xf7de06b0 (LWP 10766)  (running)
>
>
> c) Allow deleting the current thread anyway, and have it not
>    listed in the thread list.  Do some internal magic, to point
>    the current thread at some "already exited" special thread.
>    Prohibit most commands but "thread" and "info threads" in
>    this situation.  Show something like this or similar
>    in "info threads"
>
>  (gdb) info threads
>    2 Thread 0xf7d5bb90 (LWP 8506)  (running)
>    1 Thread 0xf7d5c6b0 (LWP 8503)  (running)
>
>    No selected thread.
>
> I like b) or c) because I prefer that GDB doesn't switch
> threads on me automatically.  Having 'call ExitThread (1)<enter>'
> apply to the wrong thread, because GDB decided to switch threads
> on my back between `)' and `<enter>', is a race I'd like to avoid.
>
> b) has the disadvantage that code that iterates over threads may
>   have to take care of not doing things to dead threads.  I don't
>   think there are many places.
>   It has the advantage that the user can still see some info
>   on which thread was last selected.
>
> c) has the advantage that code that iterates over threads, can still
>    rely on a thread being ptid(-1) to mean it's dead.  Easier to
>    spot a bug.  We can perhaps still show to the user which thread
>    was selected by storing that info in some global:
>
>    2 Thread 0xf7d5bb90 (LWP 8506)  (running)
>    1 Thread 0xf7d5c6b0 (LWP 8503)  (running)
>
>    The selected thread was 3, but it has exited.  Please 
>    change threads.
>
>
> We had a small internal discussion, and at the time there was
> concensus that b) would be the best option.
>
> What do you think?  Do you see other options, or problems
> with b) ?
>
> Marc, could you share with us your thoughts, in the
> perspective of a non-stop frontend developer ?
>
>   

Re: non-stop and current thread exiting

[Pedro Alves]

A Wednesday 04 June 2008 16:09:40, Pawel Piech wrote:
> Thanks Marc to point it out to me, I did indeed miss it.
> I'm also think that option c) is optimal.  I think option b) is fine as
> well, as long as -thread-list-ids returns the list of live threads only,
> even if info threads show the exited threads.

Ok, I'll see about not reporting the exited thread to MI.

Thanks,
-- 
Pedro Alves

Re: non-stop and current thread exiting

[Michael Snyder]

On Tue, 2008-06-03 at 22:53 +0100, Pedro Alves wrote:

> I see three possibilities to solve issues like these.
> 
> a) Have GDB switch to an arbitrary thread when the
>   current thread is gone.
> 
> b) Leave the currently selected dead thread in the thread
>   list, tag it as dead.  Prohibit most commands but "thread"
>   and "info threads" in this situation.  Get rid of the dead
>   thread as soon as the user/frontend switches to another
>   thread.

[...]

> c) Allow deleting the current thread anyway, and have it not
>    listed in the thread list.  Do some internal magic, to point
>    the current thread at some "already exited" special thread.
>    Prohibit most commands but "thread" and "info threads" in
>    this situation.  Show something like this or similar
>    in "info threads"
> 
>  (gdb) info threads
>    2 Thread 0xf7d5bb90 (LWP 8506)  (running)
>    1 Thread 0xf7d5c6b0 (LWP 8503)  (running)
> 
>    No selected thread.

I kind-of like "no selected thread", and then you could 
"prohibit most commands" based on those that depend on 
having a selected thread.

But my preference is not strong, and I can see the 
desire to have the previously selected thread displayed
temporarily even though it is dead.

Michael

Re: non-stop and current thread exiting

[Vladimir Prus]

Pedro Alves wrote:

> A Wednesday 04 June 2008 16:09:40, Pawel Piech wrote:
>> Thanks Marc to point it out to me, I did indeed miss it.
>> I'm also think that option c) is optimal.  I think option b) is fine as
>> well, as long as -thread-list-ids returns the list of live threads only,
>> even if info threads show the exited threads.
> 
> Ok, I'll see about not reporting the exited thread to MI.

I don't think I like this idea, as this totally negates the reason why
I like (b). Ignoring exited threads in the output of -thread-info is
a trivial thing for frontend to do, if it wishes so.

- Volodya

Re: non-stop and current thread exiting

[Vladimir Prus]

On Thursday 05 June 2008 00:13:07 you wrote:
>  As far as I remember -thread-info displays information
>  about a single thread, though I don't think it's implemented.  
>  -thread-list-all-threads which is supposed to be equivalent to info 
>  threads, could show exited threads and let the UI filter them out.  
>  However -thread-list-ids, which is actually implemented, only lists IDs, 
>  so there's no way for the UI to tell which ones are live.     

-thread-info is implemented in CVS HEAD, and can either report all threads
(when used without a parameter), or a specific thread. There's also a patch
to make it report, for each thread, if it's running or not.
-thread-list-all-threads will not be implemented, in light of current
 -thread-info behaviour.
-thread-list-ids is a historical artefact, using it is strictly inferiour
to -thread-info, and the frontend should first probe -thread-info and use
-thread-list-ids as a fallback only.

- Volodya

RE: RE: non-stop and current thread exiting

[Marc Khouzam]

> What I was thinking if that if you select a thread, and continue it,
> and the thread exits, it would be more user-friendly to gray this
> thread, add "(exited)" and then retire it next time we stop. 

That is an interesting idea.  As all UI ideas, its value will be
determined in actual usage.  But it may be nice to have this option.

> You are right that some frontend changes will be required -- but they
> are required anyway to show the "running" state of the thread, so
> seems the extra change to show "exited" state does not add much
> complexity.

If the output of thread-list-ids is simply augmented with (exited),
you are right that it would be an easy change for a frontend.

> 
> > In the case of b) or c) one point that is important for the
> > a frontend is how GDB will react to prohibited commands
> > when no thread is selected?  Will a prohibited command
> > cause an ^error or maybe an empty ^done, or something else?
> 
> With (b), you always have some thread selected. When it is actually
> exited thread, I'd say ^error is the best way. If you send a command
> and get empty ^done, while you expect some data in the response, it's
> not very good, I think.

Sounds right.

Re: non-stop and current thread exiting

[Vladimir Prus]

On Thursday 05 June 2008 17:18:20 Marc Khouzam wrote:
> 
> > What I was thinking if that if you select a thread, and continue it,
> > and the thread exits, it would be more user-friendly to gray this
> > thread, add "(exited)" and then retire it next time we stop. 
> 
> That is an interesting idea.  As all UI ideas, its value will be
> determined in actual usage.  

Of course.

> But it may be nice to have this option. 

Right.

> 
> > You are right that some frontend changes will be required -- but they
> > are required anyway to show the "running" state of the thread, so
> > seems the extra change to show "exited" state does not add much
> > complexity.
> 
> If the output of thread-list-ids is simply augmented with (exited),
> you are right that it would be an easy change for a frontend.

Actually, I plan that in the output of -thread-info, each thread will have a field
'state', that can be either 'stopped' or 'running' or 'exited'. So, a frontend
not wishing to specially display exited threads will ignore threads with 
state=exited.

(Incidentally, we might want to introduce more fine-grained values of state, like
'stepping').

> > > In the case of b) or c) one point that is important for the
> > > a frontend is how GDB will react to prohibited commands
> > > when no thread is selected?  Will a prohibited command
> > > cause an ^error or maybe an empty ^done, or something else?
> > 
> > With (b), you always have some thread selected. When it is actually
> > exited thread, I'd say ^error is the best way. If you send a command
> > and get empty ^done, while you expect some data in the response, it's
> > not very good, I think.
> 
> Sounds right.

OK.

- Volodya

Re: non-stop and current thread exiting

[Pawel Piech]

Vladimir Prus wrote:
> ...
>   
>>> You are right that some frontend changes will be required -- but they
>>> are required anyway to show the "running" state of the thread, so
>>> seems the extra change to show "exited" state does not add much
>>> complexity.
>>>       
>> If the output of thread-list-ids is simply augmented with (exited),
>> you are right that it would be an easy change for a frontend.
>>     
>
> Actually, I plan that in the output of -thread-info, each thread will have a field
> 'state', that can be either 'stopped' or 'running' or 'exited'. So, a frontend
> not wishing to specially display exited threads will ignore threads with 
> state=exited.
>
> (Incidentally, we might want to introduce more fine-grained values of state, like
> 'stepping').
>   
That's great!  It would be even better if the state change events 
included this fine-grained information as well (e.g. 
*running,reason="step").

Cheers,
Pawel

Re: non-stop and current thread exiting

[Pawel Piech]

Vladimir Prus wrote:
> On Thursday 05 June 2008 00:13:07 you wrote:
>   
>>  As far as I remember -thread-info displays information
>>  about a single thread, though I don't think it's implemented.  
>>  -thread-list-all-threads which is supposed to be equivalent to info 
>>  threads, could show exited threads and let the UI filter them out.  
>>  However -thread-list-ids, which is actually implemented, only lists IDs, 
>>  so there's no way for the UI to tell which ones are live.     
>>     
>
> -thread-info is implemented in CVS HEAD, and can either report all threads
> (when used without a parameter), or a specific thread. There's also a patch
> to make it report, for each thread, if it's running or not.
> -thread-list-all-threads will not be implemented, in light of current
>  -thread-info behaviour.
>   
That's great news.  Thanks!

> -thread-list-ids is a historical artefact, using it is strictly inferiour
> to -thread-info, and the frontend should first probe -thread-info and use
> -thread-list-ids as a fallback only.
>   
For backward, it would be great if this command would still work as 
before, i.e. it didn't include threads that exited.

Cheers,
Pawel
> - Volodya
>   

Re: non-stop and current thread exiting

[Pawel Piech]

Pawel Piech wrote:
> ...
> For backward, it would be great if this command would still work as 
> before, i.e. it didn't include threads that exited.
I meant "For backward _compatibility_, ..."

Re: non-stop and current thread exiting

[Pedro Alves]

Guys,

 Sorry for leaving the discussion for so long.  I was experimenting
with the options, so I could get a larger picture of what was implied.

I've implemented and tried the several options, and ended up settling with
the c) option.  That is, if the selected thread exits, GDB will have no 
selected thread; most commands then error out until the user/frontend
selects a thread.  Already exited threads may be left in the
internal thread list while the core still needs them, but are not
visible to the user.

Since all-stop doesn't accept commands while the inferior is running,
and switches to the thread that gets a stop event automatically, 
it is unaffected.  I propose we go with this behaviour first, and
let people experiment with it.

I'm going to post this as one of the topmost patches of a new
non-stop series, now that all it's dependencies have
been checked in.

-- 
Pedro Alves