From dev-return-13971-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sat Mar 19 05:18:54 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 89399 invoked from network); 19 Mar 2005 05:18:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Mar 2005 05:18:54 -0000 Received: (qmail 8737 invoked by uid 500); 18 Mar 2005 20:12:52 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 8319 invoked by uid 500); 18 Mar 2005 20:12:50 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 8292 invoked by uid 99); 18 Mar 2005 20:12:50 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from renown.concentric.net (HELO renown.cnchost.com) (207.155.248.7) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 18 Mar 2005 12:12:49 -0800 Received: from rcsv650.rowe-clan.net (c-24-13-128-132.client.comcast.net [24.13.128.132]) by renown.cnchost.com id PAA23451; Fri, 18 Mar 2005 15:12:44 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Errors-To: Message-Id: <6.2.1.2.2.20050318140620.03405110@pop3.rowe-clan.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 18 Mar 2005 14:11:20 -0600 To: jim@jaguNET.com From: "William A. Rowe, Jr." Subject: Re: do we still want sendfile enabled with our default conf files? Cc: dev@httpd.apache.org, dev@apr.apache.org In-Reply-To: <200503181703.j2IH3q515340@devsys.jaguNET.com> References: <200503181703.j2IH3q515340@devsys.jaguNET.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N At 11:03 AM 3/18/2005, Jim Jagielski wrote: >Seems to me, having apr_socket_sendfile universally available and >having APR deal with whether sendfile exists or how to >implement or emulate it makes the most sense... The corollary is that if apr_socket_sendfile doesn't do what the user expects, they may have a better approach than we do in fake_sendfile. The single biggest sendfile() problem is remotely mounted filesystems, which (AFAIK) most platforms don't successfully support. Does apr know this, can we determine this (in a relatively optimial manner) or is it easer for our user to determine it at a specific time (such as when httpd is going to do a stat() anyways?) I'm a little worried that fake_sendfile is less optimal than other games which can be played in multi-connection server cores, possibly future mpm designs. Bill