apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [Request for comments] new poll API
Date Mon, 29 Jul 2002 19:03:19 GMT
Brian Pane <brianp@apache.org> writes:

> Jeff Trawick wrote:
...
> >The current implementation is useful if the user has to find out if
> >the socket is readable/writable WITHOUT CONSUMING THE DATA and it is
> >inconvenient to keep track of the APR representation of the
> >pollset. If they are going to turn right around and consume the data
> >then they might as well play with socket options and call apr_recv().
> >If it is convenient to keep track of the APR representation of a
> >pollset, then it doesn't matter either way.
> >
> >I'm not sure that I see the compelling use-case but for various
> >reasons it is probably best for me to assume that there are plenty of
> >them.  Hopefully having a separate API won't be confusing to APR
> >programmers.
> >
> >ugh :)
> >
> >
> 
> hmmm...another characteristic of the use case in which the current
> API is useful is that there's exactly one descriptor involved.

strangely, I started to comment that I thought it should be a much
more *severely* limited number of descriptors...  an application with
11 descriptors to check on today may very well have 21 descriptors to
check on tomorrow and the programmer may be frazzled at having to
switch APIs (or worse yet, recompile APR with a bigger limit and thus
frazzle our users :) )

meanwhile, an application just checking on one descriptor is more
likely to still be able to use the simple API tomorrow...

> that yield a useful simplification of the two-API plan?  I'm thinking
> of something like:
> 
>   - apr_pollset API for general-purpose use (abstract interface,
>     does its own memory management, etc)
> 
>   - lightweight API that just checks a single descriptor for readability
>     or writability

That feels like a good thing to do.

> Of course, if we can only come up with a single use case for the second
> API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
> inline the poll/select call there and forget about the lightweight API
> until we find another use case.

I usually would want to wait until there are more compelling scenarios
to justify putting in an API.  A slight difference in this situation
is that we already have the API that I try to justify and what needs
to be added is the other one :)

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message