Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <rbb@covalent.net>
From: "Ryan Bloom" <rbb@covalent.net>
To: "'Jeff Trawick'" <trawick@attglobal.net>
Cc: "'Brian Pane'" <brianp@apache.org>,
	<dev@apr.apache.org>
Subject: RE: [Request for comments] new poll API
Date: Mon, 29 Jul 2002 08:52:36 -0700
Organization: Covalent Technologies
Message-ID: <016301c23717$f6363b80$0a01230a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <m3r8hmv9jd.fsf@rdu88-250-182.nc.rr.com>
Importance: Normal


> > > > I am biting my tongue here, but Jeff, you are the person who
> > > > specifically stated that the heavy-duty API was too slow for us
to
> > use.
> > >
> > > I said it was too slow and/or cumbersome to use in a particular
> > > situation that does not correspond to something an APR app would
do,
> > > so I don't consider that a valid use-case for justifying the
simpler
> > > API.  (An APR app should be using an APR timeout socket option for
> > > that situation.)
> >
> > Let me see if I understand.  Apr_poll() is too slow for APR to use,
but
> > because you don't expect APR apps to use it too often, that is okay.
> > Sorry, that doesn't hold water.
> 
> You are grasping for generalizations and taking a lot of liberties
> with the facts along the way.

Sorry, but I don't think so.  The facts are simple.  You said that
apr_poll was both too slow and too complex for use inside of APR.  To
fix that, I re-implemented apr_poll() to resolve both of those issues.
Now, (because there is an infinitely fixable memory leak), we are
throwing out the re-write, and going back to the abstract type, which
was too slow and too complex for use inside of APR.  So, where am I
mis-remembering?

> > > Like I said above, I'd first like to see a description of an APR
app
> > > that is harmed by doing the setup and using the accessor
functions.
> > > This should be helpful in determining how important it is to
support
> > > the simpler API flavor.
> >
> > Well, Greg Ames used to say all the time that apr_poll was seriously
> > hurting the performance of Apache.
> 
> Are you suggesting that Apache is a use-case to support the simpler
> flavor?  I'm not sure how.
> 
> I suspect that rebuilding the native pollset (e.g., struct pollfd
> array) every time apr_poll() is called is harmful to Apache.

It should actually perform better than the previous version of the code,
for small pollsets, which is what most people use with Apache.

> I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
> its entirety after calling poll() is harmful to Apache, which is only
> going to process the first match.

I am unable to parse this at all.  If you are talking about the current
implementation, then one of the advantages is that you don't need to do
that anymore.  If you are talking about the previous implementation,
then I really don't see which side of the discussion you are on.

Ryan