Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 63263 invoked by uid 500); 29 Jul 2002 17:42:09 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 63243 invoked from network); 29 Jul 2002 17:42:09 -0000 Reply-To: From: "Ryan Bloom" To: "'Jeff Trawick'" , Subject: RE: [Request for comments] new poll API Date: Mon, 29 Jul 2002 10:42:12 -0700 Organization: Covalent Technologies Message-ID: <016c01c23727$45cc8a00$0a01230a@KOJ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250- > > "Ryan Bloom" writes: > > > > 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 started off agreeing that the new implementation is faster for small > pollsets, but I'm not sure that is the case when you consider > steady-state operations. We save the overhead of the function call to > look up the returned events after the poll call but we pick up the > overhead of the internal call to get_event() just before poll() is > called.* That get_event() call can easily be removed in 99% of the cases (see below). > If APR had a small-pollset API and a big-pollset API, I suspect we'd > be better off in Apache just using the big-pollset API rather than > deciding at run-time which API to pick since implementing a choice > would likely introduce an extra function call which would erase any > small benefit of being able to use the small-pollset API. In how many situations would we actually need to use the big-pollset API? I would much rather just write the code to use the small-pollset API, and possible #ifdef the big-pollset API. It would be faster to use the small-pollset API, and if you _must_ have the large-pollset, then you configure for it. > > > 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. > > Here is the code I referred to as "rebuilding the abstract pollset > (apr_pollfd_t array):" > > for (i = 0; i < num; i++) { > aprset[i].rtnevents = get_revent(pollset[i].revents); > } > > *yeah, calling from Apache to APR is more expensive than an internal > APR call, but are we digging that deep to find the benefit? This is a straight bit-mask check, and in most cases, can be optimized out to a no-op. We have to write the optimization, but 99% of the time, the function call can be removed. As for the first/all rtnevents decision, Apache should be using all of the results. We don't currently, but we could and should.