Squid code questions from IRC

What follows is a sorted recapture of the IRC discussions and some
additional answers.

(14.48.55) poige: well, code inside httpAccept()
(14.49.07) poige: int *N = &incoming_sockets_accepted;
(14.49.08) poige: ...
(14.49.21) poige: (*N)++;
(14.49.27) poige: -- why that? :)

(14.53.23) hno: poige: Which Squid version are you looking at?
(14.54.03) poige: hno: squid-2.5.STABLE10-20050830
(14.54.35) hno: Please grab a more current version.. no one working on
2.5 any more.

Looks like incoming_sockets_accepted is currently unused, only ever
increased. I don't remember exactly what it may have been used for.

(14.51.16) poige: it was the first q-n. the second one is: why not using
typedef struct {} Typename and using lots of typedef inside typedefs.h?
It's rather not too convenient with go-to-definition tools
(14.54.03) hno: The typedefs split is to allow the typedefs to be used
within the struct definitions.
(14.56.04) poige: > typedefs split is to allow the typedefs to be used
within the struct definitions.
(14.56.45) poige: hno: do you mean the case when a structure has fields
inside of the same type? or what?
(14.58.02) hno: Yes. Might also be other types declared further down.
With the split of the struct and the typedef ordering gets irrelevant as
all types is declared early, defined later..
(14.58.16) hno: defined further down I meant..

(15.05.02) poige: hno: well. but what about go-to-def tools like Ctags?
(15.05.37) poige: hno: I'm sure there are not too many structs inside
Squid which are really self-referenced

Sure, ctags would navigate the source a bit better if the typedefs were
in place. But it has not been considered worth the effort to try to
unwind all the struct relations in Squid-2 to get the definitions well
structured. That's targeted for Squid-3, part or refactoring and
cleaning up the code base.

(14.55.54) poige: BTW, could i grab the diff between 2.6 and
squid-2.5.STABLE10-20050830?

You can grab a diff between 2.5.STABLE10 and 2.6 using cvs. But not sure
it's worth the effort. Why?

(14.58.25) poige: the 3rd question is about Squid-3: I know that it's a
C++ project and I deem it's rather good decision to start using C++ for
Squid, but haven't you considered starting to use C++ things inside
Squid-2?
(14.58.58) hno: Today Squid-2 is C only, and Squid-3 is the C++ version.
(14.59.12) poige: hno: I know that, of course
(14.59.20) poige: hno: but why it's so?
(14.59.24) hno: Squid-3 is a migration of Squid-2 into C++.
(14.59.44) poige: hno: what is the reason not to start using C++ inside
Squid-2?
(15.00.05) poige: I don't mean complete re-write into C++, but using
both C and C++
(15.00.15) poige: and doing new things in C++ when possible
(15.00.32) hno: Because there is Squid-3 for that. It started out as the
same code, and gradually things have been refactored into more C++
fashion.
(15.00.46) poige: hno: but Squid-3 is completely in C++
(15.01.08) poige: hno: and nobody would bet it will work just okay in
production as squid-2 would do...
(15.01.24) poige: hno: because it is a _re-write_

It's not really a re-write. It's a migration from C to C++. Large parts
of the code is still pretty much the same even if slightly restructured
or wrapped up as C++, some have been rewritten to hopefully make better
use of C++.

(15.20.38) poige: + another question:
(15.20.42) poige: for e.g.
(15.20.48) poige: commSetSelect(fd, COMM_SELECT_READ, clientReadRequest,
connState, 0);
(15.21.20) poige: and inside clientReadRequest:
(15.22.32) poige: commSetSelect(fd, COMM_SELECT_READ, clientReadRequest,
conn, 0);
(15.24.45) poige: why doing that twice?

clientReadRequest need to reinstall the event to get called again when
more data is available.

[CVS vs SVN discussion skipped]

Regards
Henrik