Brian Pane <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
