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
signature.asc
Description: Detta är en digitalt signerad meddelandedel