On Wed, Nov 25, 2009 at 10:42 AM, Niklas Edmundsson <ni...@acc.umu.se> wrote: > On Tue, 24 Nov 2009, Jeff Trawick wrote: > >> 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: > > Why am I feeling that figuring out which implementation of what works or not > should be done automagically, either by configure or at startup?
We'd agree with you on figuring out implementations at configure time, either by probing the system or by explicit decisions based on experience. I can't think of any startup-time decisions that would be practical; did you think of any in particular? > Enabling all these user-choices might backfire with "Oh, you're running foo > on bar. But of course you know that you should fiddle with the thingamajig, > because we were too lazy to do a configure test". Who is that a problem for, ignoring for a moment the notion that we've been offering mutex mechanism selection, albeit incomplete and inconsistent, for a number of years now because we were too lazy to do a configure test? > > I'm not being averse to tunability when it comes to selecting > implementations that performs better given somewhat equal functionality, but > when it's works-or-not I'd rather have the dysfunctional alternatives weeded > out and never exposed to the end user... Generally: 1. we (mostly while wearing our APR hats) do try to figure out appropriate implementations at build time so that no such configuration is required; in turn, we expect that most users don't need to configure mutexes or pollsets 2. some underlying mechanisms have unavoidable technical trade-offs that need to be put in the hands of the administrator if optimal performance is to be achieved 3. a lot of use cases for controlling the mutex mechanism or potentially the pollset are not seen first by developers; users have some pre-built apr/httpd in hand, encounter some unforeseen issue, and want to make it work; this can be especially painful for users who don't/can't build from source, such that it takes a while for a fix to a particular implementation bug or a new default choice to be widely distributed; in the meantime, configurability is a great help Something that works against absolute minimization of user problems is the moderately aggressive use of new system features when found at configure time, which may be required for advanced application use (e.g., Event MPM) but not necessary for casual users. Sometimes these newer features are more volatile in the early years. As most httpd and/or apr users get their code from a vendor, those vendors can easily select less risky (but sometimes lower performing or functionally reduced) mechanisms as their default.
