[lldb-dev] Use of thread local storage in Timer

[Zachary Turner]

On Mon, Sep 8, 2014 at 10:39 AM, Greg Clayton <gclayton at apple.com> wrote:

>
> >
> > 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.
> >
> > Does this assessment seem correct?  Or am I missing something?
>
> 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.
>
> 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).
>
> Greg
>

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.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140908/892cf9e3/attachment.html>