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

On Sat, Jan 12, 2008, Robert Collins wrote:

> > 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.

SMP will be more complicated than that. All of the data needs to be
locked; the diskd storeDirCallback() call shows at least some of the
code isn't re-entrant. Creating a seperate event loop is fine, but
since the current code doesn't have clean boundaries between modules
with sensible dataflow then my prediction is:

* someone will do this, or start to
* see that there's no bugs in their testing, and go "woo!"
* convert over other stuff
* meanwhile, 6 months down the track, we've found this wasn't the way
  to go and there are bugs introduced that are tickled in certain workloads.

Just like before..

Its still all a good start, but what we're really lacking is some
architecture to make sure these changes are all in line with some
greater project goals. If SMP will be one of those goals then so be
it.

Come on guys, lets make some damned architectural design choices if
thats where you want to head.

Adrian
Received on Sat Jan 12 2008 - 01:55:34 MST