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:28:24 GMT
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.

> Is there any reason SO_SNDTIMEO and SO_RCVTIMEO can't be used?

As far as I recall, it was just the lack of portability even among
Unix-ish platforms.  ifdef SO_SNDTIMEO probably isn't a good-enough
check for availability.

Mime
View raw message