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
