apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH]Win32 fix for corrupted byterange reply
Date Fri, 28 May 2004 16:13:50 GMT
At 07:44 AM 5/28/2004, Bill Stoddard wrote:
>Failure scenario:
>default_handler opens a pdf file to be sent via apr_sendfile (in other words, the file
is opened for overlapped i/o aka APR_XTHREAD).

Doh!  Thank you Bill for nailing down what's happened, here.

>A secondary issue I'd like to address is when the overlapped structure is created. Prior
to this patch, the overlapped structure (thefile->pOverlapped) was created in either apr_file_read()
or apr_file_write(). The following two changes move the creation of pOverlapped to apr_file_open().
 Anyone see any problems with this?

Potentially...  You create the pOverlapped  in apr_file_open(), but you
aren't selective about APR_XTHREAD...

>--- open.c      29 Jul 2003 20:19:26 -0000
>+++ open.c      27 May 2004 18:07:18 -0000
>@@ -437,6 +437,23 @@
>         apr_pool_cleanup_register((*new)->pool, (void *)(*new), file_cleanup,
>                                   apr_pool_cleanup_null);
>     }
>+    /* Create the overlapped structure if the file is opened for overlapped
>+     * i/o. Files opened for APR_XTHREAD support should always be opened for
>+     * overlapped i/o and all files opened for overlapped i/o should be marked
>+     * as APR_XTHREAD files. Note: Threads should not share an apr_file_t or
>+     * its hEvent.
>+     */
>+    if ((*new)->flags & APR_XTHREAD) {
>+        (*new)->pOverlapped = (OVERLAPPED*) apr_pcalloc((*new)->pool,
>+                                                        sizeof(OVERLAPPED));
>+        (*new)->pOverlapped->hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);

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.


View raw message