Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 75222 invoked from network); 26 Oct 2006 06:50:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Oct 2006 06:50:11 -0000 Received: (qmail 78366 invoked by uid 500); 25 Oct 2006 18:08:50 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 78321 invoked by uid 500); 25 Oct 2006 18:08:50 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 78306 invoked by uid 99); 25 Oct 2006 18:08:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 11:08:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of chip@force-elite.com designates 72.232.80.58 as permitted sender) Received: from [72.232.80.58] (HELO constant.northnitch.com) (72.232.80.58) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 11:08:38 -0700 Received: from localhost (localhost.layeredtech.com [127.0.0.1]) by constant.northnitch.com (Postfix) with ESMTP id 2C7D15C48 for ; Wed, 25 Oct 2006 13:08:17 -0500 (CDT) Received: from constant.northnitch.com ([127.0.0.1]) by localhost (constant.northnitch.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48332-04 for ; Wed, 25 Oct 2006 13:08:16 -0500 (CDT) Received: from [192.168.2.101] (c-24-5-139-163.hsd1.ca.comcast.net [24.5.139.163]) by constant.northnitch.com (Postfix) with ESMTP id 7E7A05C2F for ; Wed, 25 Oct 2006 13:08:16 -0500 (CDT) Message-ID: <453FA813.8050804@force-elite.com> Date: Wed, 25 Oct 2006 11:08:19 -0700 From: Paul Querna User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod_cache.c modules/cache/mod_cache.h References: <20061025134448.A00131A9846@eris.apache.org> <20061025155843.GD29589@redhat.com> <453F96AC.6030705@haxent.com.br> <20061025174752.GE29589@redhat.com> <453FA6D0.9070809@haxent.com.br> In-Reply-To: <453FA6D0.9070809@haxent.com.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at constant.northnitch.com X-Virus-Checked: Checked by ClamAV on apache.org Davi Arnaut wrote: > Joe Orton wrote: >>> and we must not slow the caching because of a slow client (that's why >>> I didn't pass the brigade). >> There is no other acceptable solution AFAICS. Buffering the entire >> brigade (either to disk, or into RAM as the current code does) before >> writing to the client is not OK, polling on buckets is not possible, >> using threads is not OK, using non-blocking writes up the output filter >> chain is not possible. Any other ideas? > > I think we should build the necessary infrastructure to solve this > problem once and for all. Be it either non-blocking writes, AIO or add > support to the core output filter to write data to different destinations. Thats not going to be possible until 3.0. Good luck :) -Paul