apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: Rethinking apr_socket_timeout_set
Date Fri, 24 Jun 2005 23:35:37 GMT
Jeff Trawick wrote:

>On 6/24/05, Paul Querna <chip@force-elite.com> wrote:
>
>  
>
>>I would like to look at extending the timeout API, creating a new
>>version that leaves a socket in its original state (blocking or
>>non-blocking), but still implements the Timeouts.  The SO_SNDTIMEO and
>>O_RCVTIMEO socketopts can do exactly this.  For platforms that do not
>>support them, we can emulate it but toggling to non-blocking, and using
>>apr_wait_for_io_or_timeout, just like we do now, and then reseting the
>>socket to its original state.
>>    
>>
>
>Why do you need a different timeout API?  It either works or it
>doesn't.  Provide an implementation of send*/receive*/sockopt APIs
>that can use SO_SNDTIMEO/O_RCVTIMEO, and enable it carefully.
>
>  
>
Because some applications might rely upon the API setting a socket to 
blocking or non-blocking based on the timeout.

It is documented to behave in this way, and changing such a major 
documented behavior without either an API addition or major version bump 
seems fishy.



Mime
View raw message