Re: squid-3.0-PRE3-20031008 w epoll bug?

Hi,

On Mon, 2003-10-13 at 09:37, Robert Collins wrote:
> On Sat, 2003-10-11 at 06:30, Gonzalo Arana wrote:
> > Hi,
> >
> > (I'm back to squid-gzip task now).
> > I come up to this situation:
> >
> > squid 3.0-PRE3-20031008 with epoll
> > kernel 2.4.21 patched with
> > http://www.xmailserver.org/linux-patches/epoll-lt-2.4.21-0.18.diff
> >
> > When a client requests a very long object (such as a video), squid uses
> > 100% of CPU.
> >
> > It was caused because epoll_wait returned immediately reporting that
> > connection to client can be written without blocking.
> >
> > So squid was continously calling to epoll_wait, which in turn returned
> > immediately.
>
> This is something I was about to look into. Thank you.

I'm glad I can help

>
> Two things:
> 1) why the change to COMM_TIMEOUT as the return value? That seems
> unrelated to the issue.

It is true that it does not fix the problem, but I think it is more
appropiate to return COMM_TIMEOUT if no file descriptor had any activity
after timeout specified (comm_poll.cc returns COMM_TIMEOUT in
comm_select if this happends -unless I am wrong-).

> 2) Perhaps we should set the epoll to edge triggered, which IIRC was the
> default in the early epoll API (and is not now ?)

mmm... that would require (I think) to read/write repeatedly until
EAGAIN is returned (non-blocking i/o).

I will submit my suggested patch to bugzilla (Reuben Farrelly had
reported this problem).

Hope it helps,

>
> Cheers,
> Rob

-- 
Gonzalo Arana <garana@uolsinectis.com.ar>
UOL-Sinectis S.A.