<div dir="ltr">My take was it depends on host details.  For example, I didn't track down the Windows way of getting this data, but I wouldn't be surprised if it turned into a method call to the system (which could be cached, but that's an impl detail that a method call would allow us to hide).<div>
<br></div><div>I thought it made it more flexible on unknown details for current/future platforms to have it be a function call.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 11, 2014 at 8:52 AM, Ed Maste <span dir="ltr"><<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 11 July 2014 11:04, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>

> Hi all,<br>
><br>
> This patch looks to provide a non-#ifdef manner to help choose better<br>
> debugger-defined thread names when operating on platforms that don't support<br>
> long thread names.  We have code that attempts to pick a smarter short name<br>
> when a longer thread name is too long to set, but that can fail too when the<br>
> shortened variant is still too long.<br>
<br>
</div>I'm happy with this change, although it could be done as a<br>
compile-time constant instead, no?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>