> 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
