Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 88060 invoked by uid 500); 13 Dec 2002 20:07:16 -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 88047 invoked from network); 13 Dec 2002 20:07:15 -0000 Date: Fri, 13 Dec 2002 20:07:17 +0000 From: Joe Orton To: dev@apr.apache.org Subject: Re: APR_TCP_NOPUSH Message-ID: <20021213200717.GB1247@manyfish.co.uk> Mail-Followup-To: dev@apr.apache.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Dec 13, 2002 at 10:12:17AM -0800, Ryan Bloom wrote: > So, I continue to wonder, how is it useful to have this in a _portable_ > run-time, when the concept isn't at all portable? Will you also be removing threads, IPv6, and all the other stuff which isn't implemented on every single platforms APR supports? I don't care much about this particular issue, but I don't buy the argument: as Aaron said, setting TCP_CORK is a useful optimisation on platforms which support it. You can write a portable application which uses TCP_CORK if available and doesn't if it's not - just as you can write a portable app which can use threads. If you drop it from the APR API that just makes it considerably harder for people to use the optimisation: they would have write the autoconf checks, make their code a mess of ifdefs, call apr_os_sock_get to get the fd out, blah blah blah. I'd wager the end result would be a less "portable" application than if the code was in APR, since it leaves more things for the app to screw up. Having said that, leaving NOPUSH in the API as undocumented as it is currently also allows the app to screw up and be unportable, so there's an argument for removing it. Regards, joe