apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [PATCH] poll.c pollacc.c ab.c
Date Sun, 04 Aug 2002 04:13:35 GMT
William A. Rowe, Jr. wrote:

> At 10:15 AM 8/3/2002, Rob Saccoccio wrote: 


>> Its not clear to me which poll API should be used when.  Apache uses the
>> deprecated API.  Some thoughts on the subject should probably be put in
>> poll.h and Apache updated.
>
>
> I'm as stumped as you.  FWIW, both should work.  It makes no difference
> right now,


If you're polling on a single file/socket descriptor,
both APIs do about the same processing on the first poll
(mostly just copying from the apr_pollfd_t to the OS's
pollfd struct).  If you expect to have to call poll on
that same descriptor repeatedly, the apr_pollset API
is more efficient than the apr_poll API, because the
pollset API doesn't have to repeat this setup work on
subsequent requests.  On the other hand, to take
advantage of this property of the apr_pollset API,
you need to be able to keep track of the pollset
object between calls.  In situations where it's
prohibitively complex for the app to maintain a pollset
object, the apr_poll API is simpler to use.

For larger numbers of descriptors, the apr_pollset
API scales better than apr_poll, as the pollset code
doesn't need to do an O(n) copy on each poll call.

Thus my rule of thumb for choosing between the poll
APIs is:
  if (very small number of file descriptors) {
      if ((poll will be repeated multiple times) &&
          (application can keep track of a pollset object)) {
          use apr_pollset API;
      }
      else {
          use apr_poll API;
      }
  }
  else {
      use apr_pollset API;
  }

> but will when Brian implements /dev/poll [or /dev/epoll] and I attack
> WSAAsyncSelect, both of which require the accessor-based api to be easily
> reusable [performantly] from poll to poll. 


Definitely.

--Brian



Mime
View raw message