Re: [RFC} threadsafe internal profiler

On 11/01/11 22:08, Kinkie wrote:
> On Tue, Jan 11, 2011 at 8:03 AM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>> The profiler aufs assertions are caused by the profiler not being thread
>> safe but attempting to account operations inside each of the AIO threads.
>> Lack of thread safety is due to the stack the profiler maintains of what
>> states are currently being counted.
>>
>> I don't believe we should be maintaining such a stack. Instead I think we
>> should leverage the existing system stack by having the PROF_start(X) macro
>> create a counter object in the local scope being counted. When the local
>> scope exists for any reason the system stack object will be destructed and
>> the destructor can accumulate the counters back into the global data.
>
> +1. I like this.
>

FWIW; I looked at coding it up. There is one major side effect with the
change:

  It seems the current profiler is trying some fancy accounting to
eliminate time when child-scopes were operating. But only if they had
their own counters.

The proposed change will give us high level functions displayed with
much longer running times than before. Since the new profiler scheme
will account child run-times in with the parent function/method. However
these will be more consistent (if not accurate) than previous outputs.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.10
   Beta testers wanted for 3.2.0.4