Right, that is what is happening now. If GDB returns a name (which always happens on Linux) we show the name, while if GDB does not return anything (which always
happens on Windows and Mac), we don’t show the name at all.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alena Laskavaia
Sent: Wednesday, December 03, 2014 7:39 PM
To: Marc-André Laperle
Cc: CDT General developers list.
Subject: Re: [cdt-dev] Proposed change in thread naming
So implementation should be not host specific but just based on what gdb reports or not, no?
On Wed, Dec 3, 2014 at 3:19 PM, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
Mac's pthread has thread names but GDB doesn't report them (tested GDB 7.7.1). So GDB would need to be updated to support this.
Marc-André
Our default names are empty strings, so we do that. But we override this method anyway. So it does not really matter.
Mac supports thread name since 10.10 no?
On Wed, Dec 3, 2014 at 1:31 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Marc Khouzam
> Sent: Friday, November 28, 2014 4:37 PM
> To: 'elaskavaia.cdt@xxxxxxxxx'; 'CDT General developers list.'
> Subject: Re: [cdt-dev] Proposed change in thread naming
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Alena Laskavaia
> > Sent: Friday, November 28, 2014 3:38 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] Proposed change in thread naming
> >
> > What are the numbers after thread name suppose to mean? Where it is
> > coming from?
>
> That is the OS Id of the thread. On Linux GDB provides that when getting
> thread information. The MI field is "target-id".
> On Windows, I was told it does not or always gives 0.
>
> > If you don't have thread name we use "unnamed" at qnx, i.e. it would
> > look like
> >
> > 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)
>
> That is a good point. If some threads are named, we should show names for all
> threads, so [unnamed] sounds good.
>
> That will mean that on Windows (and Mac) all threads will show [unnamed].
>
> > If threads never have names of their system people should override
> > label provider (or whatever they need to override)
>
> Yes, except that for DSF-GDB on Windows and Mac, we are those people :) I'll
> be honest, I don't really want to have a special label for Windows or Mac
> because with remote debugging things get even more difficult than they would
> already be to differentiate.
>
> Do you think showing [unmade] all the time for all threads is a problem?
Since Windows and Mac never have a thread name, I don't want to show
[unnamed] for every thread.
On Linux, all threads have a name, even if it is the default one.
So, I don't see when to trigger [unnamed].
I won't put that unless someone can give me a scenario.
Thanks
Marc
>
> >
> >
> > On Fri, Nov 28, 2014 at 10:38 AM, Marc Khouzam
> > <marc.khouzam@xxxxxxxxxxxx> wrote:
> > One detail I forgot to mention (that made me want to add the <> of
> > format
> > C) is that for systems that don’t provide the thread names, the B
> > format look like this:
> > B -
> > MyProcess [1530] [cores: 2,3]
> > Thread #1 18787 [core: 3] (Suspended: Container)
> > Thread #2 18788 [core: 2] (Running: Container)
> > Thread #3 18789 [core: 3] (Suspended: Container)
> > Thread #4 18797 [core: 3] (Running: Container)
> >
> > This will be a rare case on Linux, but for Windows, it will always look like:
> >
> > B -
> > MyProcess [1530]
> > Thread #1 0 (Suspended: Container)
> > Thread #2 0 (Running: Container)
> > Thread #3 0 (Suspended: Container)
> > Thread #4 0 (Running: Container)
> >
> > I wasn’t a big fan of having just a space between the thread id digit
> > and the OS id digits, but I’m also not too bothered by it. I wanted
> > to point it out so that you had all the info.
> >
> > I’ve posted a one-line patch that implements B. People can try out
> > and comment on it:
> > https://git.eclipse.org/r/#/c/37276/
> >
> > Thanks
> >
> > Marc
> >
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Marc Khouzam
> > Sent: Friday, November 28, 2014 7:23 AM
> >
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: Re: [cdt-dev] Proposed change in thread naming
> >
> > Looks like B is clearly more popular. I'm glad when there's clear
> > feedback like this. I'll modify my patch to follow B.
> >
> > Once committed we will still have about two months before the release
> > so it can still be adapted if something else comes up.
> >
> > Thanks everyone
> >
> >
> > Sent from my Android phone using TouchDown (www.nitrodesk.com)
> >
> >
> > -----Original Message-----
> > From: Sergey Prigogin [eclipse.sprigogin@xxxxxxxxx]
> > Received: Friday, 28 Nov 2014, 0:43
> > To: CDT General developers list. [cdt-dev@xxxxxxxxxxx]
> > Subject: Re: [cdt-dev] Proposed change in thread naming
> >
> > From pure aesthetic reasons I like B more than C.
> >
> > -sergey
> >
> > On Thu, Nov 27, 2014 at 5:28 PM, Marc Khouzam
> > <marc.khouzam@xxxxxxxxxxxx> wrote:
> > Well, I don't want to say "I picked C" as it should be a consensus,
> > but yes, I prefer C :)
> >
> > When you say "more aligned with JDT", I gather it is because the
> > thread name is between square brackets like JDT? Because the rest
> > does not match JDT at all. Solution C is more aligned with what CDT
> > does now, which I thought might be better than trying to match JDT.
> >
> > But in the end I want whatever is best for our users, and I'm not very
> > good at UI stuff, so I'll go with the majority. Anyone else have a
> > preference between the below B or C? IIRC, we had another vote for B
> > already, so it is in the lead.
> >
> > Thanks
> >
> > Marc
> >
> > ________________________________________
> > From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on
> > behalf of Alena Laskavaia [elaskavaia.cdt@xxxxxxxxx]
> > Sent: November 27, 2014 6:35 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] Proposed change in thread naming
> >
> > Are you saying you picked C? I still think B is better because its
> > aligned with JDT more
> >
> > On Thu, Nov 27, 2014 at 4:36 PM, Marc Khouzam
> > <marc.khouzam@xxxxxxxxxxxx> wrote:
> > Hi,
> >
> > Thanks for the feedback.
> > So we've converged to (I've added all fields that I see in my Debug view):
> >
> > A-
> > MyProcess [1530] [cores: 2,3]
> > Thread [1] MyProcess 18787 [core: 3] (Suspended: Container)
> > Thread [2] MyProcess 18788 [core: 2] (Running: Container)
> > Thread [3] Worker 18789 [core: 3] (Suspended: Container)
> > Thread [4] Heartbeat 18797 [core: 3] (Running: Container)
> >
> > or
> >
> > B -
> > MyProcess [1530] [cores: 2,3]
> > Thread #1 [MyProcess] 18787 [core: 3] (Suspended: Container)
> > Thread #2 [MyProcess] 18788 [core: 2] (Running: Container)
> > Thread #3 [Worker] 18789 [core: 3] (Suspended: Container)
> > Thread #4 [Heartbeat] 18797 [core: 3] (Running: Container)
> >
> > I like A because it simply inserts the name of the thread into our
> > existing format.
> > And I like B because putting the name in brackets makes it more
> > understandable. Also, thread names can have spaces, so it is good to
> > have some kind of grouping symbol.
> > I tried to have a hybrid of the two:
> >
> > C-
> > MyProcess [1530] [cores: 2,3]
> > Thread [1] <MyProcess> 18787 [core: 3] (Suspended: Container)
> > Thread [2] <MyProcess> 18788 [core: 2] (Running: Container)
> > Thread [3] <Worker> 18789 [core: 3] (Suspended: Container)
> > Thread [4] <Heartbeat> 18797 [core: 3] (Running: Container)
> >
> > We had an internal discussion here and we found that the different
> > grouping delimiter (<>) helps differentiate between different groups.
> > And although we liked #1, #2 for the id, we thought we would follow
> > the current solution more and keep [1], [2].
> >
> > Does someone disagree?
> > If not, this will become the new 'face' of the CDT Debug view for the
> > next release.
> >
> > Thanks!
> >
> > Marc
> >
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-
> > bounces@xxxxxxxxxxx]
> > > On Behalf Of Simon Marchi
> > > Sent: Wednesday, November 26, 2014 10:54 AM
> > > To: cdt-dev@xxxxxxxxxxx
> > > Subject: Re: [cdt-dev] Proposed change in thread naming
> > >
> > > On 2014-11-26 10:39 AM, Alena Laskavaia wrote:
> > > > In this case second set square brackets really don't add
> > > > anything,so it really becomes #1. Which is fine with me too, since
> > > > it is what we show now anyway :)
> > > >
> > > > Another variant with JDT similar look
> > > >
> > > > 5 -
> > > > MyProcess [1530]
> > > > Thread #1 [MyProcess] (Suspended: Container)
> > > > Thread #2 [MyProcess] (Running: Container)
> > > > Thread #3 [Worker] (Suspended: Container)
> > > > Thread #4 [Heartbeat] (Running: Container)
> > >
> > > This suggestion is the one I prefer so far.
> > > _______________________________________________
> > > 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
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
|