squid-3 comm reworking, pass 1

Hiya,

Here's the first part of my comm reworking for squid-3.

http://www.creative.net.au/diffs/20060918-squid3-comm-7.diff

I've created another(!) array holding the read/write callbacks
for comm_read and comm_write. I've deleted the CommWrite path
and converted comm_read and comm_write into C paths rather
than C++ paths. I've run through and unified the calls to
comm_write and comm_old_write. This code deletes the need
to constantly be creating/destroying temporary read state
and io callbacks (and I'll do the same for the connect path shortly.)

This code does look like a step back, but here's my eventual
aim:

* I'm aiming to bring the rest of the comm code back into C.
  I don't believe any of the abstractions (save the deferred
  reads abstraction) is actually buying us anything in the
  comm codebase. I'll leave the deferred manager how it is
  but convert it over to using comm_read() and delete the old-style
  IO callback list.

* I'm going to sit down with Robert and think up a replacement
  method for doing the deferred reads. I don't believe the
  deferred reads logic belongs anywhere near the comm layer.
  I believe it should be something done at the StoreEntry/MemObject
  layer where there's enough information to determine when to
  schedule a comm read and how much.

* I'll then sit back with the clean code and slowly convert all
  of this mess into something resembling a C++ API, but only after
  we've all had a little more experience (and squid-3 is out the
  door and stable!) with an eye for the future.

Why? I don't believe the current abstractions to be useful.
Noone has really made any real push to use alternative network/
communication layers which don't provide Berkeley sockets and
file descriptors. The real way to do this is to properly abstract
out everything beginning at the filedescriptor layer and allow
people to drop in replacement "fd", IPC, comm and disk implementations
of a fixed API. This would be nice to have in the future.
The C API, with perhaps enough fruit to support stuff like the
Callback type, should do us fine for now.

Its entirely possible my view here will change once this code has
been written but I really think the comm layer needs to be tidied up
and made as efficient as possible before we attempt to make things
"better".

A drian
Received on Mon Sep 18 2006 - 01:18:42 MDT