Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 15440 invoked from network); 20 Sep 2006 11:32:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Sep 2006 11:32:23 -0000 Received: (qmail 34716 invoked by uid 500); 20 Sep 2006 11:32:22 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 34683 invoked by uid 500); 20 Sep 2006 11:32:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 34672 invoked by uid 99); 20 Sep 2006 11:32:22 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Sep 2006 04:32:22 -0700 X-ASF-Spam-Status: No, hits=0.1 required=5.0 tests=FORGED_RCVD_HELO Received: from ([207.113.241.148:39065] helo=iss04.interliant.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 20/75-00532-1C621154 for ; Wed, 20 Sep 2006 04:32:18 -0700 Received: from EX-009.mail.navisite.com (ex-009.interliant.com [207.113.240.184]) by iss04.interliant.com (8.10.2/8.10.2) with ESMTP id k8KBWFY06710 for ; Wed, 20 Sep 2006 06:32:15 -0500 (CDT) Received: from [192.168.0.168] ([213.202.111.57]) by EX-009.mail.navisite.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 06:32:09 -0500 Message-ID: <451126B8.1040204@apache.org> Date: Wed, 20 Sep 2006 13:32:08 +0200 From: Mladen Turk User-Agent: Mozilla MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: svn commit: r442492 - /apr/apr/branches/1.2.x/network_io/unix/sockets.c References: <20060912065935.9BDA11A981A@eris.apache.org> <20060913123006.GA32224@redhat.com> <20060919161731.GA15564@redhat.com> <45103012.6030803@rowe-clan.net> <45111C98.1060702@apache.org> <20060920112359.GA3729@redhat.com> In-Reply-To: <20060920112359.GA3729@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Sep 2006 11:32:09.0577 (UTC) FILETIME=[68B24D90:01C6DCA8] X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Joe Orton wrote: > > If the API guarantee is "may allocate memory on failure" then the fix is > bad and should be reverted; the caller will have to do the > create/destroy dance anyway so it's needless overhead whether large or > small. > This was the case without my patch to unix/sockets.c I was "will not allocate on Win32, will always allocate on unix". > If the API guarantee is "will not allocate memory on failure" then > clearly this fix is necessary. I think this option makes more sense. > Of course we can have "will always allocate memory regardless of failure" which was the case before the pacth (unix only), but like said it's resource wasteful, and IMO we all agree on that. Regards, Mladen.