Re: poll optimisation problems

On Tue, May 30, 2000, Andres Kroonmaa wrote:
>
> > > I can only speculate about comm_select() looping FD from 0..npollfds,
> > > and inside the loop calling handlers that most probably would call
> > > SetSelect, which is altering npollfds via poll_update_pollfds().
> > > This isn't clean code, I think ;) It can run past initial npollfds
> > > in the for loop. Whether this is a problem or not is not clear to
> > > me, but we shouldn't have such interactions unless they are wanted.
> >
> > But if npollfds changes in the loop, that should be ok.
> Not sure what you mean. npollfds++ (static var) causes the for loop
> to parse more FD's than were polled. and it seems that each READ
> handler makes it increment. I'd think that if you stepped on a FD
> that wants to read, you could end up calling read handler endlessly
> with EAGAIN...and within the single for loop? but maybe I've
> misunderstood the code.

Hrm. Ok, my brain folded. I'm happy thats all gone. Have you checked
out what I just committed to the commloops branch? In reality,
npollfds shouldn't be modified until after the loop is scanned..

> > > Other than populating pollfds[].events we shouldn't touch
> > > pollfds[] further on. Of course, when we close FD, we'd need to
> > > set pollfds[].fd = -1. We might want to do the same when there
> > > are no handlers or we defer the FD.
> >
> > I'm doing it now when there are no handlers, but the deferred FD
> > is the problem.
> >
> > The deferred FD is the problem. Slow fds when delay pools can also
> > be a problem but I'm sure thats easier to fix. When a FD is deferred,
> > right now the only way to handle it is to check it in poll/select,
> > and then throw it away if its deferred. A CPU waste, and it kills
> > the performance using kqueue. I am thinking of killing deferred FDs
> > entirely and adding a comm_read() function which should make it easier
> > (and cleaner) ..
>
> Perhaps the simplest way would be to hack defer into a form of
> "defer until" with squid internal time nad say 1 sec granularity?
> Maybe we can wrap in comm.c internal checkTimeouts() handler?
> Then we could keep .events but set fd = -1 until defer state is
> cleared?

From what I can see, most of the deferred reads evilness can be lost
if reads are scheduled when data is actualy wanted, not always scheduled
and then thrown away when we're actually not ready for the data.

Do you think a comm_read() function would be useful? Similar to comm_write()
except there's no free func and it will return as much data as a single read
can supply. I had written one a while back when I was playing with a POSIX
AIO squid ..

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.