As with mutex implementations, APR pollset implementations, or the
underlying OS support, are occasionally broken for some
configurations; the access to multiple implementations in APR 1.4.x
lends itself to allowing the user to specify a non-default pollset
implementation.
For example, the following could be used to work around the temporary
epoll sysdef confusion on Linux, or (cough) the port_getn() interface
challenges on Solaris:
# use poll() instead of epoll/port_create/kqueue/whatever
Poll default poll
As with the Mutex directive directive, a module would register a poll
type name in the pre-config hook then call
ap_{pollcb,pollset}_create() in lieu of apr_{pollcb,pollset}_create(),
and magic would happen.
APR pollsets have a special consideration that mutexes do not: Some
features such as APR_POLLSET_THREADSAFE are optional, and not
implemented uniformly among underlying implementations. The simple
and event MPMs require this particular optional feature. The Poll
directive would not provide any special magic here. If you declare
"Poll default poll" and try to use the Simple MPM, the Simple MPM
would fail startup. You could of course configure
Poll default poll
Poll simple-io eventport # or epoll
to work around the startup failure, but that most likely defeats the
original purpose -- avoiding a problem in the advanced implementation.
--/--
Beyond working around implementation problems, perhaps the ease of
selection in an important application would motivate developers to
support more mechanisms in APR?
