Apache for Windows can get caught in a tight loop whild handling CGI requests. Here's how:

sendwithtimeout() sets  errno to EINTR on a timeout and returns SOCKET_ERROR (-1) to
the caller. The caller reissues sendwithtimeout, which then succeeds. errno is left set to
EINTR. Eventually,  another read is attempted on one of the CGI pipes (ap_bgets in mod_cgi,
or ap_send_fb_length) which goes down into ap_read. ap_read issues a Win32 ReadFile to read
from the pipe. If this read fails, it returns -1 to the caller. If errno
is still set to EINTR, the caller will retry the read and so the loop begins.

The solution is quite simple. buff.c relies heavily on errno. Anytime Win32 calls are used
in code that uses errno, we need to always, ALWAYS explicitly set errno when a Win32 system
call fails (via either errno = GetLastError() or errno = WSAGetLastError()). Since Win32
does not use EINTR, this problem should not occur.

PR: 3599 3971 4245 4430 4758 5171
Submitted by:	Thanks to Jim.Patterson@cognos.com who discovered the loopig section of
code.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@84018 13f79535-47bb-0310-9956-ffa450edef68