Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.160.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=jlDV3/JMWo/Q0L3wV8KG3U7j0zxREnn2bxxJq4B4mFHy+y5Gu9RKuK1F7BdKyKRJF6
         ImLwtGmG4Z3XtBGW0dqbutQ5ejwjSOIHgJt2SJED9KUB5HktZCpIPypoXjOLXY7+lX71
         LEtRpqfS+wV/d7u7YTqmL5H2z68gMeTjTzo/U=
MIME-Version: 1.0
In-Reply-To: <Pine.GSO.4.64.0911251634490.12513@hatchepsut.acc.umu.se>
References: <cc67648e0911240739l6d2ce6a2heb29f3f371dfb704@mail.gmail.com>
	 <Pine.GSO.4.64.0911251634490.12513@hatchepsut.acc.umu.se>
Date: Wed, 25 Nov 2009 11:10:52 -0500
Message-ID: <cc67648e0911250810o1f79ec27y6eccd54695578225@mail.gmail.com>
Subject: Re: a directive to select the pollset implementation?
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 25, 2009 at 10:42 AM, Niklas Edmundsson <nikke@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.