apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: apr_poll should not have been removed
Date Sat, 22 Nov 2003 22:42:09 GMT
--On Thursday, November 20, 2003 9:33 PM -0500 Jeff Trawick 
<trawick@attglobal.net> wrote:

> The older comments look like an agreement that we'd keep the simple
> apr_poll() API for simple uses like apr_wait_for_io_or_timeout() and the new
> pollset API would be for the more complex cases.  There was quite a bit of
> argument about this type of thing many months ago.  I remember the recent
> commit that moved the deprecated stuff to one part of the header file, but
> the nuance of marking apr_poll() was lost on me :)

I'll chime in and say that apr_poll() is inefficient in both memory and time. 
Most seriously, the API doesn't allow for using more advanced poll-like APIs.

Therefore, I think APR apps *should* be using apr_pollset API.  The pollset 
API will be faster in the long run as it can ultimately leverage fast pollset 
implementations (like /dev/poll) without changing the application.  It has a 
cleaner API than apr_poll() as the apr_pollfd_t passed in rather is returned - 
so you easily know what fd is returned.  Furthermore, it avoids the 
degenerative memory cases of apr_poll().

So, count me as one of those who disagrees - apr_poll should be removed before 
1.0.  By switching to this at 1.0, we can later deploy APR libraries built 
with /dev/poll in the 1.0 timeframe with the performance benefits.  Multiple 
interfaces to the same underlying API isn't good.  -- justin

Mime
View raw message