<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 8, 2014 at 10:39 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
> This would solve the portability issue since TLS destructors would no longer be needed, and making porting all of our TLS code to use llvm support libraries very easy.<br>
><br>
> Does this assessment seem correct?  Or am I missing something?<br>
<br>
</span>The idea is you can place a "Timer" object anywhere in code and it can some profiling by timing how long it takes. If another function makes another "Timer" object, it will push itself on the stack, stop the previous timer, wait until it destroys itself and pop itself back off the stack, keep a long running total time spent doing the task, and then reactivate the timer above it.<br>
<br>
So the TLS destructor are currently required. If TLS destructors aren't supported on the platform, then this class should be disabled for that platform (hollow it out and have it do nothing for platforms that don't support it).<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">It sounds like you're talking about getting a function's exclusive time?  As in, if function A calls B, and you create a timer in both A and B, then the timer in A will compute timeof(A) - timeof(B)?  If not, and if it's sufficient to just time functions from start to end along with all the child functions that execute, then llvm also has its own timer class that we could use.  See llvm/Support/Timer.h.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As for the TLS destructors, it seems this is only necessary in the case that a thread is cancelled?  Because if a thread routine runs to completion, we could just call Timer::CleanupThreadSpecificData() or something.  Could we use pthread_cleanup_cancel() for the same purpose, and then have our thread trampoline cleanup any timer-specific TLS data before it returns to catch the non-cancellation case?</div><div class="gmail_extra"><br></div><div class="gmail_extra">My main concern is that I don't want to expose a generic thread-local class that supports TLS destructors if TLS destructors aren't generic enough to be available on all platforms.  It makes it too easy to make use of them in generic code, breaking other platforms.</div></div>