Re: comm_*_incoming changes

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

        I'm slightly confused by the wording of the description. For
example, you're saying wait 16 I/O events if there was just activity,
but wait 2 if there was no recent activity. My confusion is with the
definition of recent. Is what you're trying to say really:

        Recheck after 16 I/O events after fresh activity on the incoming
sockets, and then recheck every 2 events thereafter until activity occurs,
at which point go back to the "wait for 16 events" again? If so, then I
believe the option wording is also slightly confusing, because "rate"
implies a number/time, not a number. Something like incoming_io_check,
and incoming_io_recheck. Then the wording could be incoming_io_check means
check for incoming connections/ICP after this number of I/O events, and
incoming_io_recheck means recheck for new conn/ICP every this number of
I/O events if no new events happened after incoming_io_check events (or
something like that).

        Stew.

> How does this sound for a compromise:
>
> # TAG: incoming_min_rate
> # TAG: incoming_max_rate
> # These specify how often the "incoming" sockets should be
> # checked, compared with established connections. Note, the
> # "incoming" sockets are where we accept new HTTP connections and
> # where we process ICP queries.
> #
> # If there was just activity on an incoming socket, then we will
> # check the incoming sockets again after processing the next
> # 'incoming_max_rate' I/O events. If there was not any recent
> # incoming activity, we check incoming sockets again after
> # processing the next 'incoming_min_rate' I/O events.
> #
> #incoming_min_rate 2
> #incoming_max_rate 16
>
> Also, I have replaced comm_{select,poll}_incoming() with a function
> which just calls the handlers directly, and I have put while() loops
> in the handler functions.
>
> Duane W.
>

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:50 MDT