apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Rethinking apr_socket_timeout_set
Date Fri, 24 Jun 2005 23:42:50 GMT
On 6/24/05, Paul Querna <chip@force-elite.com> wrote:
> 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.

They wouldn't work on Windows anyway, FWIW.

> It is documented to behave in this way, 

Where?

Mime
View raw message