Re: Deferred reads

On 1 Jun 2000, at 2:13, Adrian Chadd <adrian@creative.net.au> wrote:

> > > Now, from what I can see these can be replaced with either periodic events
> > > or properly scheduled reads.
> >
> > I don't like the sound of "periodic events." How do you choose the
> > period? If the period is too long then the request is delayed
> > unnecessarily. If its too short, and you still don't want to read,
> > then you have almost the same problem you're trying to fix -- a lot of
> > cycles spent not reading.

 the period is chosen already now. eg. client_side uses conn->defer.until
 to implement different defer times.
 btw, why is defer handler implemented as boolean function, and is not
 returning time for the defer to exist? boolean response from the func
 says very little: "you can't read FD _exactly_now_", while if it would
 return a hint "you can't read FD for about xxx mSecs" it could be used
 for good.

> > Also, can you explain what a properly scheduled read is?
> > How is that supposed to work?
>
> For example, only scheduling a read when you only want data, and not
> when its deferred. I'll pull up some example code to demonstrate what
> I'm thinking.

 actually, squid used to skip defered FD's from being polled, which
 seems to have changed in the latest devel (commloops?). So the defer
 issue is a new one, probably introduced by commloops rewrite?

> > kqueue implementation, so maybe you can educate me further. If a
> > kqueue event (or whatever) says that data is read, but you want to
> > ignore it (or, the application isn't ready to accept the data), how do
> > you handle that?
>
> The trouble is that in poll/select, you can throw away a returned
> fd rather easily because you should have all the other fds that are
> ready to service, and you only sacrifice a little CPU. With an event
> driven system like kqueue, if you throw away the read because you are
> not ready to deal with it yet (a la deferred reads), you schedule
> another one and it will return immediately. If you end up with
> a few deferred reads, then you end up getting mostly these read ready
> fds. kqueue doesn't have any way of dealing with this. You can't
> tell whether a fd is going to be deferred at event add time, and you
> don't get an update when the read defer is active and inactive.

 I think there is not so much of a difference. If you poll deferred
 FD and then skip handling it, you have the same issue as with kqueue:
 if this is the only FD to poll, the whole CPU is burned on polling
 FD that we are not going to service. So in both cases we need to
 omit deferred FD from being checked for IO readyness.

> I'm open to more suggestions. :)

 perhaps you want to create a temp list of defered FD's where you
 save away registered events and recheck this list for undefered
 FD's at the end of every poll loop or every second?
 Maybe there is point in changing deferCheck api so that it can
 hint on the amount of time to defer? I think subsec precision
 would be nice then.
 perhaps you want to implement "unDefer" callbacks?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Network Development Manager
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed May 31 2000 - 15:05:39 MDT