On Sat, Nov 22, 2003 at 02:42:09PM -0800, Justin Erenkrantz wrote:
> --On Thursday, November 20, 2003 9:33 PM -0500 Jeff Trawick
> <[EMAIL PROTECTED]> 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 :)
Regards,
joe
