> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > "Ryan Bloom" <[EMAIL PROTECTED]> writes: > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > > "Ryan Bloom" <[EMAIL PROTECTED]> writes: > > > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > > > > > > A little bird told me that FD_ZERO() burns lots of cycles in > > > > > apr_wait_for_io_or_timeout(). It turns out that this is an easy > > > > > conversion to poll(), which doesn't have such overhead in the > > > > > interface. > > > > > > > > > > This works for me with some testing (timeouts on read and write > > work > > > > > for me). > > > > > > > > Can we remove the #ifdef's by just using apr_poll here? > > > > > > I'd rather we not, since that introduces a fair amount of extra > > > overhead. > > > > Then let's get rid of the overhead. > > redesign the API
The redesign the API, but FIX the performance problem! > > If we don't use apr_poll, then > the > > overhead is maintenance, > > the marginal extra maintenance is certainly something I can live with > here... this is an important path within APR... if we can use the > most efficient mechanism without much extra maintenance then we > should... You are missing the point. If apr_poll() is to be useful to external projects, then it must perform well. If it performs so poorly that we refuse to use it inside of APR, then it couldn't possibly be useful to external projects. That is straight-line reasoning in my mind. Why in the world would we leave an API in APR that performs so poorly that we refuse to use it in our own library? Doing that boggles my mind. Ryan
