Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Proposed change in thread naming 
What I don't like about the first #2 (BTW, I didn't put two 2s on purpose, it was a copy/paste mistake :))
is that the thread id looks like it is a numbering of that particular type of thread.
So
  Thread [Worker-3] (Suspended: Container)
make me think there should be a [Worker-1] and [Worker-2], which is not the case.
That is why I slightly modified it for #3 (second #2)
  Thread [Worker][3] (Suspended: Container)

So I am hesitant to choose a similar look as JDT when we don't behave the same.

I'll try to come up with something to easily overidde the "Thread" string.

As for "Container" it means the reason for the Suspended state is that the "container" (the process)
was interrupted.  In all-stop mode, when hitting a breakpoint all threads stop.  The thread that actually hit
the breakpoint is labelled (Suspended: Breakpoint) while the others (Suspended: Container) since they were stopped
because the entire process was stopped.
In non-stop mode, where each thread stops on its own, you only see (Suspended: Breakpoint)

Marc

________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Alena Laskavaia [elaskavaia.cdt@xxxxxxxxx]
Sent: November 25, 2014 8:14 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Proposed change in thread naming

I kind of like idea to look similar to JDT debugger (first #2) (not because it better but for consistency)
Include in your example how it will look like if thread does not have name at all?
Java btw have at least two types of thread "Thread" and "Daemon Thread", maybe we can provide some API to change that prefix too
for the case you worried about

Btw what is "Container" suppose to mean (Suspended: Container)?
We have it too, I am not sure what is usefullness of this info.

On Tue, Nov 25, 2014 at 4:10 PM, Mikhail Khodjaiants <mikhailkhod@xxxxxxxxxxxxxx<mailto:mikhailkhod@xxxxxxxxxxxxxx>> wrote:
I am Ok with either #1 or first #2.

On 25/11/2014 3:41 PM, Marc Khouzam wrote:

If the debugger returns nothing we default to “Thread” like we do now.

You and Mikhail bring up a good option I had overlooked, which is to add the name of the thread, instead of replacing the “Thread” string.
One thing we should be aware of though is that people that extend DSF-GDB or DSF, and already provide a thread name would already be seeing the format:

ProcessName

-          ThreadName [id]

so changing the format will affect them.

Now, about a new format, I think we should keep showing the thread index all the time, as it allows to give GDB command-line commands to a thread.  So we have all kinds of possibilities, but if we look at what Alena and what Mikhail proposed we could have something like:

1-
MyProcess [1530]
  Thread [1] MyProcess (Suspended: Container)
  Thread [2] MyProcess (Running: Container)
  Thread [3] Worker (Suspended: Container)
  Thread [4] Heartbeat (Running: Container)

2-
MyProcess [1530]
  Thread [MyProcess-1] (Suspended: Container)
  Thread [MyProcess-2] (Running: Container)
  Thread [Worker-3] (Suspended: Container)
  Thread [Heartbeat-4] (Running: Container)

2- (should have been #3)
MyProcess [1530]
  Thread [MyProcess][1] (Suspended: Container)
  Thread [MyProcess][2] (Running: Container)
  Thread [Worker][3] (Suspended: Container)
  Thread [Heartbeat][4] (Running: Container)

other permutations.

I like #1 most.

Another point to note is that the current solution allows people to remove the work “Thread” by naming their threads.  This is potentially something used in multicore situations.  The solution proposed above, would make this slightly harder, although still possible by overriding the code.

Please speak up if you care about this.

Thanks

Marc


From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
Sent: Tuesday, November 25, 2014 1:59 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Proposed change in thread naming

How do you get information how it is really called? If debugger does not give you anything at all, what would you show?

We show it like this btw for our debugger (i.e. name after thread id)
Thread [1] Control (SIGWAITINFO) (Suspended : Signal : SIGINT:Interrupt)
Thread [2] unnamed (CONDVAR) (Suspended : Container)
Thread [3] Socket (RECEIVE) (Suspended : Container)
Thread [4] unnamed (RECEIVE) (Suspended : Container)

On Tue, Nov 25, 2014 at 1:46 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx<mailto:eclipse.sprigogin@xxxxxxxxx>> wrote:
+1 for the proposed change.

-sergey

On Tue, Nov 25, 2014 at 10:41 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
Hi,

for a while GDB has been providing the name of each thread of a process.  We were not making use of that information but instead using the string "Thread" in the Debug view.  http://eclip.se/378154 aims to improve this and show users the real name of each thread.

Say the program explicitly names its threads "Worker" and "Heartbeat":

MyProcess                will become           MyProcess
  - Thread [1]                                                  - Worker [1]
  - Thread [2]                                                  - Heartbeat [2]

This is obviously better as it shows the user the names she has chosen.  However, if the program does _not_ name its threads, we will now show them as they are really known by the OS instead of using "Thread". I feel that this is the correct thing to do anyway but I wanted to bring up this UI change to the community.  So, with the proposed changed, on Linux for example, a process where the user does not care to name the threads

MyProcess                will become           MyProcess
  - Thread [1]                                                  - MyProcess [1]
  - Thread [2]                                                  - MyProcess [2]

On Linux, the first thread is named like the process and each thread takes the name of the thread that created it.  So, effectively, we'll most often see every thread name be the same as the process name.

If the user were to list thread names using any other tool, the names would be as we now propose to show them, as that is the real name of the thread for the OS.  So, I feel this change makes sense.

Any comments?  I'll wait the week to see if anyone has an opinion, and if not, I'll commit the change.

Thanks

Marc

Back to the top