On Mon, Jan 07, 2008, Alex Rousskov wrote:
> We should be able to improve that by redesigning onclose API or comm
> internals. I think that should be discussed after async calls are fully
> working though. The fundamental AsyncCall design idea is that modules
> like comm should not call other code directly. All such calls should be
> async. I still think that design is the right one as it will help us to
> make Squid3 robust and, eventually, SMP-scalable (with other lesser
> advantages like better debugging and profiling).
Can you explain the SMP and the profiling advantages a bit better please?
I hate having a nested mess of callbacks, but it at least lets me
profile the callback chains a lot easier by grouping profiling info by
specific call stacks (which profilers do natively.)
The problem right now is that there's so many little functions in Squid which
get profiled seperately and trying to extract any meaningful profiling info
as to what is taking the time requires quite a bit of post-processing.
I'd love to find some tools which made this easier under FreeBSD/Linux.
Finally, I can't see how async callbacks will make SMP much easier to implement.
Could someone give me some insight into this?
Adrian
Received on Mon Jan 07 2008 - 18:34:47 MST
This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST