Re: cvs commit: squid/src comm.c

Yah, the comm write code is not reentrant for a given fd. You need to
let the write complete before sending another write. I ended up noting
whether I had triggered a write, and if I had buffering all the data
coming down the path & then on clientCommWriteComplete pushing the
buffered data thoguh. (the reason being that a) at the end of the filter
chain you do not know how much data to expect (size can change) and b)
always delaying until a local client_sock_buf_size size buffer is full
doesn't make sense).

Only programmer error will trigger that behaviour, so I think perhaps a
fatal() would do the trick.

Rob

----- Original Message -----
From: "Duane Wessels" <wessels@squid-cache.org>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, February 24, 2001 8:58 AM
Subject: Re: cvs commit: squid/src comm.c

>
>
> On Sat, 24 Feb 2001, Robert Collins wrote:
>
> > I actually found that assertion useful in developing the filter
code:
> > I called CommWriteMembuf twice within a single function call. I
would
> > have mucked things up royally without that assertion there to show
me
> > the error of my ways.
>
> If it is an error to call CommWriteMembuf() twice, then we should
> add a warning, or change the "if (state != NULL)" block to an
> assertion I guess.
>
> As written, the assertion was pointless because there are
> two pointers pointing to the same memory. One pointer got
> reset correctly, but the 'state' pointer did not.
>
>
Received on Fri Feb 23 2001 - 15:09:51 MST