Re: [RFC} threadsafe internal profiler

On 12/01/11 14:20, Alex Rousskov wrote:
> On 01/11/2011 02:08 AM, 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.
>
> I have a crude patch that implements such scope-based profiling. We used
> it to find performance regressions in Squid3 (still an ongoing project)...
>
> I would be happy to find that patch and post if somebody wants to polish it.
>
> Thank you,
>
> Alex.

Yes please. I threw together a patch last night. I'm happy compare and
merge the two for inclusion.

Amos

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