Re: A question about comm_select.

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Sun, 25 Feb 2001 19:28:58 +0100

Yes, if you are interested in information which arrived SINCE you called
it the last time, but you still have other less important information to
process from the last call...

There is one huge select()/poll() over all of the active connections,
and while the data is being processed, a smaller check is performed with
some interval for new connections and ICP messages. This to ensure that
SYN or UDP queues does not get flooded only because there is much to do.

--
Henrik Nordstrom
Squid hacker
cachemail@procache.com wrote:
> 
> Dear All
> 
> As much as I know using a system call has a lot of overhead,
> so Is it logical that using select three or more times, while
> we can use it just once?
> 
> Regards,
> V.Fk
> 
> On Sat, 24 Feb 2001, Henrik Nordstrom wrote:
> 
> > cachemail@procache.com wrote:
> > >
> > > Dear All,
> > >  In the comm_select, there are special code for icp and http, and we
> > >  check them at the beginging by using comm_select_icp_incoming and
> > >  comm_select_http_incoming, each one has its own select. In the main
> > >  part of comm_select we use another select. In some parts of there codes
> > >  there are some commDeferRead()s. I have some questions as follow:
> > >
> > >         1) Why there are seperated part for select and is it possible to
> > >                 use just one select instead?
> >
> > Because these are checked more often than the other filedescriptors.
> >
> > >
> > >         2) Why do we use seperated commDeferRead()s in each part? There
> > > are
> > >                 commDeferRead()s after the main select(). I think before
> > >                 the select and after that we check the commDeferRead().
> > >                 Why? Is it possible to do it just once?
> >
> > It is called per connection.
> >
> > --
> > Henrik Nordstrom
> > Squid hacker
> >
Received on Sun Feb 25 2001 - 14:33:41 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:34 MST