You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by st...@apache.org on 2001/07/01 17:13:35 UTC
cvs commit: apr/network_io/win32 sendrecv.c
stoddard 01/07/01 08:13:35
Modified: network_io/win32 sendrecv.c
Log:
Back out this portion of Bill Rowe's large file support patch. We should not
use the event handle in the apr_file_t to do overlapped i/o on a socket. We
either need to wait for io completion on the socket or create a thread specific
event handle. This fixes the seg fault we were seeing when serving a cached
file on Windows.
Revision Changes Path
1.41 +14 -18 apr/network_io/win32/sendrecv.c
Index: sendrecv.c
===================================================================
RCS file: /home/cvs/apr/network_io/win32/sendrecv.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- sendrecv.c 2001/06/06 16:05:26 1.40
+++ sendrecv.c 2001/07/01 15:13:34 1.41
@@ -258,16 +258,12 @@
/* Initialize the overlapped structure */
memset(&overlapped,'\0', sizeof(overlapped));
- if (file->pOverlapped)
- overlapped.hEvent = file->pOverlapped->hEvent;
-#ifdef WAIT_FOR_EVENT
- else
- overlapped.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
-#endif
if (offset && *offset) {
- file->pOverlapped->Offset = (DWORD)*offset;
- file->pOverlapped->OffsetHigh = (DWORD)(*offset >> 32);
+ overlapped.Offset = *offset;
}
+#ifdef WAIT_FOR_EVENT
+ overlapped.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
+#endif
/* Handle the goofy case of sending headers/trailers and a zero byte file */
if (!bytes_to_send && hdtr) {
@@ -324,14 +320,15 @@
if (!rv) {
status = apr_get_netos_error();
if (status == APR_FROM_OS_ERROR(ERROR_IO_PENDING)) {
- if (overlapped.hEvent)
- rv = WaitForSingleObject(overlapped.hEvent,
- (DWORD)(sock->timeout >= 0
- ? sock->timeout : INFINITE));
- else
- rv = WaitForSingleObject((HANDLE) sock->sock,
- (DWORD)(sock->timeout >= 0
- ? sock->timeout : INFINITE));
+#ifdef WAIT_FOR_EVENT
+ rv = WaitForSingleObject(overlapped.hEvent,
+ (DWORD)(sock->timeout >= 0
+ ? sock->timeout : INFINITE));
+#else
+ rv = WaitForSingleObject((HANDLE) sock->sock,
+ (DWORD)(sock->timeout >= 0
+ ? sock->timeout : INFINITE));
+#endif
if (rv == WAIT_OBJECT_0)
status = APR_SUCCESS;
else if (rv == WAIT_TIMEOUT)
@@ -379,8 +376,7 @@
}
#ifdef WAIT_FOR_EVENT
- if (!file->pOverlapped || !file->pOverlapped->hEvent)
- CloseHandle(overlapped.hEvent);
+ CloseHandle(overlapped.hEvent);
#endif
return status;
}
Re: cvs commit: apr/network_io/win32 sendrecv.c
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
> stoddard 01/07/01 08:13:35
>
> Modified: network_io/win32 sendrecv.c
> Log:
> Back out this portion of Bill Rowe's large file support patch. We should not
> use the event handle in the apr_file_t to do overlapped i/o on a socket. We
> either need to wait for io completion on the socket or create a thread specific
> event handle. This fixes the seg fault we were seeing when serving a cached
> file on Windows.
This was a bug, but this commit is the wrong answer. It slows down everything _except_
the XTHREAD case, and probably breaks some other edge cases.
I'm backing this out, working up the proper patch that does _NOT_ create the pOverlapped
or mutex for an XTHREAD'ed apr_file_open, then use the thread-private stack flavor of
each in this code if they are aren't defined on the apr_file_t.
While I could create the thread-private stack mutex and pOverlapped structure in a macro,
so we can set this this up for any filesystem call using XTHREAD. But IMHO reads and writes
are invalid for an XTHREAD-opened file, and we need to add some read_at_offset/write_at_offset
to provide a legal mechanism for calling read and write when a single apr_file_t is shared
between multiple threads.
Bill
Re: cvs commit: apr/network_io/win32 sendrecv.c
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
> stoddard 01/07/01 08:13:35
>
> Modified: network_io/win32 sendrecv.c
> Log:
> Back out this portion of Bill Rowe's large file support patch. We should not
> use the event handle in the apr_file_t to do overlapped i/o on a socket. We
> either need to wait for io completion on the socket or create a thread specific
> event handle. This fixes the seg fault we were seeing when serving a cached
> file on Windows.
This was a bug, but this commit is the wrong answer. It slows down everything _except_
the XTHREAD case, and probably breaks some other edge cases.
I'm backing this out, working up the proper patch that does _NOT_ create the pOverlapped
or mutex for an XTHREAD'ed apr_file_open, then use the thread-private stack flavor of
each in this code if they are aren't defined on the apr_file_t.
While I could create the thread-private stack mutex and pOverlapped structure in a macro,
so we can set this this up for any filesystem call using XTHREAD. But IMHO reads and writes
are invalid for an XTHREAD-opened file, and we need to add some read_at_offset/write_at_offset
to provide a legal mechanism for calling read and write when a single apr_file_t is shared
between multiple threads.
Bill
Re: cvs commit: apr/network_io/win32 sendrecv.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On 1 Jul 2001 stoddard@apache.org wrote:
> stoddard 01/07/01 08:13:35
>
> Modified: network_io/win32 sendrecv.c
> Log:
> Back out this portion of Bill Rowe's large file support patch. We
> should not use the event handle in the apr_file_t to do overlapped
> i/o on a socket. We either need to wait for io completion on the
> socket or create a thread specific event handle. This fixes the seg
> fault we were seeing when serving a cached file on Windows.
Woohoooo!!! Thanks, Bill! So are we working on keepalive requests now,
too, dare I ask?
PS: Is there any way to get ab to compare the results of each request it
makes to verify that they're all the same and/or that they match a
reference copy of the requested document? I realize this would slow down
ab quite a bit and therefore possibly underestimate the speed of the
server, but it'd be a useful option for testing things like this...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA