apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: apr_poll should not have been removed
Date Sun, 23 Nov 2003 21:22:23 GMT
On Sat, Nov 22, 2003 at 02:42:09PM -0800, Justin Erenkrantz wrote:
> --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().

/dev/poll is so heavyweight though, that makes a good argument for
keeping the lightweight apr_poll() interface around: you could say
apr_poll scales down but not up, apr_pollset* scales up but not down.

e.g. how would you make a /dev/poll-based apr_pollset_* implementation
as efficient as a simple poll() in apr_wait_for_io_or_timeout?  keeping
an fd to the device open for the lifetime of each apr_{file,socket}_t
doesn't sound like fun :)



View raw message