Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48BC471D.4020805@rowe-clan.net>
Date: Mon, 01 Sep 2008 14:48:45 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [community] 2.3.0 alpha on October 1?
References: <48AE1049.1080309@rowe-clan.net>
 <52D3BF705D654A2195DA3328384007F2@bspc0>
 <C348E82F-0F5D-43A8-B5EF-C4025662C6C8@jaguNET.com>
In-Reply-To: <C348E82F-0F5D-43A8-B5EF-C4025662C6C8@jaguNET.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Jim Jagielski wrote:
> 
> On Aug 31, 2008, at 9:49 AM, Bing Swen wrote:
>>
>> To my knowledge, the "one thread per connection" network i/o model is a
>> suboptimal use
> 
> threads vs. events is certainly not, imo, a finalized debate
> yet with a known winner or loser. Maybe 5-10 years ago events
> had a "clear" advantage but today that is hardly the case...
> 
> Not saying that httpd shouldn't (or won't) have an true
> event driven MPM, but it is hardly the manna the masses
> claim it to be.

Depending on traffic shaping, it most certainly will be an improvement but
the question is entirely about what sorts of gains, and will they be worth
it for the "classic" module authoring community to make the sometimes
painful changes necessary to support a free-threaded server.  Many modules
achieved worker mpm compatibility with TLS, which isn't a free-threaded
solution.

It was perfect for the slow internet + slower and less capable machines,
but even as the bandwidth of individual clients grows, so too has the
"typical" machine (now multi-core, very fast performance, etc).

The only way to settle the debate though will be to demonstrate it :)