Re: COMM_SELECT_WRITE or not

On Mon, Feb 05, 2007, Alex Rousskov wrote:
> Hi there,
>
> While applying the BodyPipe changes to ftp.cc and http.cc, I would like
> to move lots of common code into ServerStateData, the class that both
> FTP and HTTP "servers" already share.
>
> One of the differences I noticed is how FTP and HTTP write request body
> pieces when receiving them from the client_side. Before doing each
> write, FTP calls commSetSelect(COMM_SELECT_WRITE) in
> ftpDataWriteCallback(). HTTP appears to simply call comm_write, without
> bothering to wait for the file descriptor to be selected for writing.
>
> To me, it looks like http.cc code (and client_side code as well) are
> using "optimistic" writes. They rely on comm_* code to handle situations
> where the descriptor is not ready. Ftp.cc seems to be more cautious, but
> I do not know why.

Its a hold-over to how things were done in the past. Please try to take
advantage of comm_write() where appropriate as it'll make things easier
to port in the long run.

(Heck, Squid-2 suffers from the same split-brain personality when it comes
to network IO. I'm pretty sure comm_write() was there far before I got
to the networking layer.)

> Is the difference between ftp.cc and http.cc essential? Can I remove
> commSetSelect(COMM_SELECT_WRITE) logic from the FTP code and use bare
> comm_write calls instead?

Yup.

> Alex.
> P.S. FWIW, the BodyPipe work is progressing better than I expected. I
> was even able to remove a large chunk of ICAP code, and the result may
> be easier to comprehend and tweak. The server side (http.cc and ftp.cc)
> code is the most complex one as it has to deal with up to three(!)

Nifty! Its good to see squid-3 work progressing.

Adrian
Received on Mon Feb 05 2007 - 17:43:19 MST