Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <40B76F0F.6040305@wstoddard.com>
Date: Fri, 28 May 2004 12:55:43 -0400
From: Bill Stoddard <bill@wstoddard.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: apr-dev@apache.org
Subject: Re: [PATCH]Win32 fix for corrupted byterange reply
References: <40B73429.50707@wstoddard.com>
 <6.1.0.6.2.20040528110808.0570dec0@pop3.rowe-clan.net>
In-Reply-To: <6.1.0.6.2.20040528110808.0570dec0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> Read the comment above.  APR_XTHREAD can apply any time we need
> to share the same file across multiple threads.  DuplicateHandle(), for
> an overlapped open, actually points at the same file.  The only risk here
> is that if you make this change, you must also create a new, unique
> pOverlapped structure for the second apr_file_t, we cannot share the
> same pOverlapped object, we cannot duplicate an overlapped handle
> for non-overlapped access, so apr_file_dup(2) must be handled as a
> seperate overlapped object with a unique pOverlapped structure.
> 
> Bill  
> 

Yep, apr_file_dup is a big hole. Maybe I'll just leave the creation of the overlapped structure in read/write 
adn just make the change to the seek code. I'll let it stew in my brain over the weekend.

Bill