What I do not like about the current implementation is that we are
forced to always change the socket into non-blocking on a unix platform
to use timeouts.
This causes nasty things, like sendfile() returning EAGAIN all the time,
because the socket is non-blocking.
I would like to look at ext
On 6/24/05, Paul Querna <[EMAIL PROTECTED]> 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 t
Jeff Trawick wrote:
On 6/24/05, Paul Querna <[EMAIL PROTECTED]> 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 socketop
On 6/24/05, Paul Querna <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
>
> >On 6/24/05, Paul Querna <[EMAIL PROTECTED]> 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 stil
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-block
On 6/24/05, Paul Querna <[EMAIL PROTECTED]> wrote:
> >>>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 re
