Joe Orton wrote: > On Tue, May 24, 2005 at 11:28:50PM -0700, Paul Querna wrote: > >>[EMAIL PROTECTED] wrote: >> >>>Author: jorton >>>Date: Tue May 24 23:24:19 2005 >>>New Revision: 178386 >>> >>>URL: http://svn.apache.org/viewcvs?rev=178386&view=rev >>>Log: >>>* build/apr_hints.m4 (APR_PRELOAD): Prevent use of poll() on Darwin. >> >>I believe this should only apply to Darwin <8.0 or Mac OSX <10.4.0. >> >>poll() is known to be broken on the older versions, but it appears to >>work correctly in 10.4. > > > Al Begley @ Apple does not concur: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=34332#c15 > > neither does the fact that everywhere I keep reading that poll() is > "deprecated" on Darwin and is implemented as a wrapper for select() in > libc. Or did that change in 10.4?
As far as I know, it changed in 10.4. The man page no longer mentions depreciation, and it seems to work correctly. It would be nice to get an 'official' word out of someone @apple.com. >>This could all be mute if we added a KQueue backend for apr_poll(). I >>had the code to do it at one time, I will look at adding it later this week. > > > apr_poll() is not used by apr_wait_for_io_or_timeout(). > Yep. It uses poll() directly, or a pollset. Maybe we should just preload WAITIO_USES_POLL to 0 on darwin, instead of killing poll completely? > But making apr_poll() use a kqueue-like interface is a really bad idea > anyway, as I've argued before. apr_poll() should be efficient to use > occasionally or for small numbers of fds; and will be necessarily faster > than apr_pollset_* in those cases since it requires just one system call > - no overhead for setting up and tearing down the kqueue/epoll/... > interface. Perhaps, but if they could be cached, and re-used, it is faster if we will be doing it multiple times. On FreeBSD, I commonly saw kqueue to have about 20% lower latency than poll(). -Paul
