Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 80938 invoked from network); 8 Feb 2006 23:23:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Feb 2006 23:23:54 -0000 Received: (qmail 74688 invoked by uid 500); 8 Feb 2006 23:23:51 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 74549 invoked by uid 500); 8 Feb 2006 23:23:50 -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 74534 invoked by uid 99); 8 Feb 2006 23:23:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 15:23:49 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [207.155.248.18] (HELO dreadnought.cnchost.com) (207.155.248.18) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 15:23:49 -0800 Received: from [192.168.0.21] (c-24-13-128-132.hsd1.il.comcast.net [24.13.128.132]) by dreadnought.cnchost.com id SAA23591; Wed, 8 Feb 2006 18:23:31 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Errors-To: Message-ID: <43EA7CEE.1000909@rowe-clan.net> Date: Wed, 08 Feb 2006 17:21:18 -0600 From: "William A. Rowe, Jr." User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org Subject: apr_file_flush fluxored Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Apparently we've completely neglected the mutex locking around the public apr_file_flush API. From an external perspective, if a mutex exists, it must be used. From an internal perspective, we invoke flush from within an already-mutexed block of code (lock, flush, operation, unlock) so we absolutely don't want to mutex it. I'm thinking of an apr_file_internal_flush API for the existing non-mutexed flavor, and make the public apr_file_flush API obtain the mutex where it's appropriate, and invoke apr_file_internal_flush inside the mutex code. Thoughts? Bill