Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 53515 invoked from network); 1 Dec 2008 17:46:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Dec 2008 17:46:36 -0000 Received: (qmail 60834 invoked by uid 500); 1 Dec 2008 17:46:35 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 60775 invoked by uid 500); 1 Dec 2008 17:46:35 -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 60752 invoked by uid 99); 1 Dec 2008 17:46:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 09:46:35 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.22] (HELO smtpauth16.prod.mesa1.secureserver.net) (64.202.165.22) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Dec 2008 17:45:07 +0000 Received: (qmail 2206 invoked from network); 1 Dec 2008 17:45:53 -0000 Received: from unknown (76.252.112.72) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 01 Dec 2008 17:45:52 -0000 Message-ID: <493422CF.8020206@rowe-clan.net> Date: Mon, 01 Dec 2008 11:45:51 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: new modules in trunk References: <49339D94.3000602@force-elite.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Kevac Marko wrote: > On Mon, Dec 1, 2008 at 11:17 AM, Paul Querna wrote: >> mod_heartmonitor: Collects these Multicast heartbeats for other modules to >> use. > > Interesting. Is there other modules that create separate thread(s) for > bypassing request-response thing? Considered doing this for the data vs. control channel of mod_ftp, but it's essentially not necessary and introduces additional overhead to set up and tear down threads during operation. A thread pool was an alternative, but in the end, it looked too expensive to consider.