win32/apr_socket_recv() vs others...

[Brad Nicholes <BN...@novell.com>]

    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?



Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

Re: win32/apr_socket_recv() vs others...

[Jeff Trawick <tr...@attglobal.net>]

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.

Re: win32/apr_socket_recv() vs others...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 04:25 PM 1/27/2003, 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 believe you can call this a design error or oversight.  (Some of these
areas have been moving targets and some platforms have drifted.)

Please feel free to suggest a patch or a test for correct behavior.

Bill