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

Hi,

The early epoll API was virtual impossible to write for, because it did
not do an initial poll on new file descriptors you register an interest
for, so it could not know about notifications that happened before then.
  I just about tore my hair out trying to code around that, and still
had race conditions to deal with that looked to be impossible to get rid
of. Coding for edge triggered in squid involves much *pain* and
*suffering*... :-)

Having said that Gonzalo's solution seems to be something along the
lines of what I have looked at in the past. Although, I have to wonder
if it won't break in some cases, because if I am not mistaken there are
places in the code that set the read_handler and write_handler settings
in the squid file descriptor tables without calling CommSetSelect() or
am I mistaken about that?

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.
>
> Two things:
> 1) why the change to COMM_TIMEOUT as the return value? That seems
> unrelated to the issue.
> 2) Perhaps we should set the epoll to edge triggered, which IIRC was the
> default in the early epoll API (and is not now ?)
>
> Cheers,
> Rob

-- 
David Nicklay
Location: CNN Center - SE0811A
Office: 404-827-2698	Cell: 404-545-6218