Thread overview
Thread names in Visual Studio and Mago
Sep 15, 2019
Random D user
Sep 18, 2019
Rainer Schuetze
Sep 18, 2019
Random D user
Sep 20, 2019
Rainer Schuetze
September 15, 2019
I've been trying to set thread names for debugging, but it seems Mago just ignores all names.

Using WinAPI function SetThreadDescription() I can get thread name to show up in other programs (such as the very sleepy profiler), but not in Visual Studio and Mago debugger. I also tried the exception method as described here:
https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019

core.thread.Thread also seems broken in terms of thread name. It seems to just set a local name for the thread, but not communicate that to the os. I suppose threads in Windows are nameless outside of debugging, so perhaps that was just a poor d-runtime design choice.
Anyway, Mago doesn't seem to look up the d-runtime name either.

Is there a way to show thread names in Visual Studio Mago? or is it just unsupported.

Also it would be cool if the d runtime would name it's threads, so that it would be easier and faster to pick the correct one.

September 18, 2019

On 15/09/2019 20:11, Random D user wrote:
> I've been trying to set thread names for debugging, but it seems Mago just ignores all names.
> 
> Using WinAPI function SetThreadDescription() I can get thread name to
> show up in other programs (such as the very sleepy profiler), but not in
> Visual Studio and Mago debugger. I also tried the exception method as
> described here:
> https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019

SetThreadDescription works for me (in VS2019).

If you are using the visualdproj project, do not use "Mago" as the debugger, the "Visual Studio" debugger work better and have D support through a mago based expression evaluator extension.

> 
> 
> core.thread.Thread also seems broken in terms of thread name. It seems
> to just set a local name for the thread, but not communicate that to the
> os. I suppose threads in Windows are nameless outside of debugging, so
> perhaps that was just a poor d-runtime design choice.
> Anyway, Mago doesn't seem to look up the d-runtime name either.
> 
> Is there a way to show thread names in Visual Studio Mago? or is it just unsupported.
> 
> Also it would be cool if the d runtime would name it's threads, so that it would be easier and faster to pick the correct one.
> 

Please report to https://issues.dlang.org/
September 18, 2019
On Wednesday, 18 September 2019 at 07:30:21 UTC, Rainer Schuetze wrote:
>
>
> On 15/09/2019 20:11, Random D user wrote:
>> I've been trying to set thread names for debugging, but it seems Mago just ignores all names.
>
> SetThreadDescription works for me (in VS2019).
>
> If you are using the visualdproj project, do not use "Mago" as the debugger, the "Visual Studio" debugger work better and have D support through a mago based expression evaluator extension.

Yes, I'm using VS2019.
Interesting. I indeed have been using Mago (pretty old project files too).
I did not know that "Mago" was the wrong debugger to use. I think it used to be so that it was the preferred and more feature complete (i.e. correct) debugger.

Thanks.
And what it's worth, I think you're doing high value work with Visual D, much appreciated.

September 20, 2019

On 18/09/2019 19:55, Random D user wrote:
> On Wednesday, 18 September 2019 at 07:30:21 UTC, Rainer Schuetze wrote:
>>
>>
>> On 15/09/2019 20:11, Random D user wrote:
>>> I've been trying to set thread names for debugging, but it seems Mago just ignores all names.
>>
>> SetThreadDescription works for me (in VS2019).
>>
>> If you are using the visualdproj project, do not use "Mago" as the debugger, the "Visual Studio" debugger work better and have D support through a mago based expression evaluator extension.
> 
> Yes, I'm using VS2019.
> Interesting. I indeed have been using Mago (pretty old project files too).
> I did not know that "Mago" was the wrong debugger to use. I think it
> used to be so that it was the preferred and more feature complete (i.e.
> correct) debugger.

It was preferred before the debugger extension existed (2017), and the
latter only works for VS2012 and later (unlikely to be an issue now). I
guess I should add that info to the combo box somehow.

> 
> Thanks.
> And what it's worth, I think you're doing high value work with Visual D,
> much appreciated.
> 

Thanks.