apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: cvs commit: apr/network_io/win32 sendrecv.c
Date Mon, 02 Jul 2001 19:18:06 GMT
> 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


Mime
View raw message