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