Re: async-calls squid3/src comm.cc,1.81.4.16,1.81.4.17

On Fri, 2008-01-11 at 16:06 +0100, Henrik Nordström wrote:
> ons 2008-01-09 klockan 21:13 +1300 skrev Amos Jeffries:
>
> > That this code is currently depending on that implicit guarantee when it
> > should not be. This change is the perfect time to drop that implicit
> > dependency and make it clean (bug free!). Having one precursor call
> > schedule its successor is the cleanest and fastest way to do that.
> > Run-time speed optimizations can wait, but this is a stability issue.
>
> Even the day when we are fully SMP with support for 80 CPU cores call
> order of calls scheduled form the same job will be preserved, unless
> they are explicitly made as callouts for parallell processing which I
> don't see will be needed.
>
> To scale on SMP it's very important you keep the processing of the same
> job on the same CPU. Each time data needs to cross from one CPU to the
> other is very expensive, and each time you need to syncronize access for
> all CPUs is really bad..
>
> Ideally there will be one worker thread per CPU core, each with their
> own filedescriptors, async queues, comm loop etc. Possibly even memory
> management.
>
> It's still too early to say if this will be done using threads or
> processes. But what we certainly will not see is that everything uses a
> global async-call queue managed by all CPUs. If you desing that way then
> you could just as well not go the SMP path and you'll probably get
> better performance..

That is one of the key points of the current code in head; because the
dispatch and queue mechanisms are not based on globals, you can just
instantiate a new loop where that is appropriate. As long as the new
stuff can be used by passing code that needs to do async calls a handle
to the loop (or a dispatcher, or whatever), then this is still directly
feasible.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.