Perhaps a comment to this effect should be committed to the code to avoid this question from coming up in the future.
-- Matt Emmerton ----- Original Message ----- From: "Brad Nicholes" <[EMAIL PROTECTED]> To: <[email protected]>; <[EMAIL PROTECTED]> Sent: Monday, January 27, 2003 7:34 PM Subject: Re: win32/apr_socket_recv() vs others... > Ah, you are right. apr_socket_timeout_set() sets the send and receive > timeouts which are then handled by winsock. Therefore apr_socket_recv() > doesn't need any additional wait code. That's the information I > needed. > > thanks > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> Jeff Trawick <[EMAIL PROTECTED]> Monday, January 27, 2003 > 4:47:44 PM >>> > Brad Nicholes wrote: > > > When I compare the win32 implementation of apr_socket_recv() > against > > other implementations, one thing seems to jump out. On all other > > platforms the apr_socket_recv() function calls > > apr_wait_for_io_or_timeout() if recv() returns and EWOULDBLOCK and > there > > is a timeout specified in the sock structure. In the Win32 > > implementation any timeout value in the sock structure is simply > > ignored. Is there a reason for this or is it an oversight? > > > I see that Mr. Rowe has answered differently already, but I thought the > > answer was this: > > When the timeout is set (and stored in apr_socket_t), a Win32 socket > option is set so that the Windows kernel handles the timeout without > APR > having to use multiple syscalls to perform the same function. >
