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

On Thu, 2003-10-16 at 03:54, David Nicklay wrote:
> Hi,

> I have been looking at this in a little more detail now. Currently, I
> am using read_handler and write_handler as variables to make decisions
> about what epoll is interested in inside of the kernel. Now I can see
> that this is not a good way to do things, because these do not always
> jive with what the kernel epoll has.
>
> Unfortunately, the reason I did it this way to start with was because
> epoll does not have a function to query what a file descriptor is
> interested in (I need to send a note to the author of epoll about this).
> In the meantime what I am going to have to do to make all of this work
> correctly is find a place to store an extra variable or two in which I
> can store what epoll actually has (kludge kludge kludge).

I've spoken with said author already. The recommendations where to:
1) Track the kernel state we've requested ourselves. (I suggest a vector
in the comm_epoll file).
2) Deregister for stuff we can't handle if we are using if we are using
level triggered, OR
3) switch to edge triggered which was the default when you wrote the
code.

In terms of read handlers and write handlers w/edge triggered IO - yes,
there would be race conditions if you work based on squid having a write
handler, when using edge triggered. You do need to note what event has
become ready, and mark it in comm_epoll as ready for that until an
EAGAIN occurs on the matching call. This may need some refactoring of
the comm modularity, to allow the comm_[epoll|poll|select etc] module to
be aware of read errors and the like.

Switching to edge triggered again is probably the best first step.

Cheers,
Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.