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-
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]
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> wrote:
+1 for the proposed change.
On Tue, Nov 25, 2014 at 10:41 AM, Marc Khouzam <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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
