FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Frediano Ziglio wrote:
> http://h71000.www7.hp.com/doc/82final/6529/6529pro_030.html

(nice resource!) 

http://www.opengroup.org/onlinepubs/000095399/functions/send.html
http://www.opengroup.org/onlinepubs/000095399/functions/write.html

"[For] a socket, write() shall be equivalent to send() with no flags set."

> The problem is that in some situations
> tds_select can return even if data are not pending (or not possible to
> write) and catching these errors keep looping.

What situations?  

I can't see a *standard* way for the code to fail in the way it did. 

http://h71000.www7.hp.com/doc/82final/6529/6529pro_020.html#r_send

But then there are always nonstandard, undocumented ways.  Sigh.   

I agree with your analysis, but not DEC's implementation!  EINPROGRESS is
not just a nonstandard return from write(2), it's nonsensical.  We already
already know select(2) gave us the green light.  EAGAIN or EWOULDBLOCK
will nevertheless tell us if *nothing* can be written.  *Partial* success
is not an error, whether or not O_NONBLOCK is set.  Who needs yet another
alias for "can't write to nonblocking socket"?  

That said, the list of error conditions is quite long and the code a bit
simplistic.  I wonder why we haven't bumped into this before.  Here's the
union of possible error conditions and how I think they should be treated:
 

Error: 
 erc          vendors      description                             
 ------------ ------------ ----------------------------------------
 EACCES       posix        The calling process does not have the ap
 EBADF        posix vms    The socket argument is not a valid file 
 ECONNRESET   posix vms    A connection was forcibly closed by a pe
 EDESTADDRREQ posix vms    The socket is not connection-mode and no
 EFAULT             vms     The message argument is not in a readab
 EIO          posix        An I/O error occurred while reading from
 EMSGSIZE     posix vms    The message is too large to be sent all 
 ENOBUFS      posix vms    Insufficient resources were available in
 ENOTCONN     posix vms    The socket is not connected or otherwise
 ENOTSOCK     posix vms    The socket argument does not refer to a 
 EOPNOTSUPP   posix vms    The socket argument is associated with a
 EPIPE        posix        The socket is shut down for writing, or 
Retry: 
 EAGAIN       posix        The socket's file descriptor is marked O
 EINPROGRESS        vms    (undocumented)
 EINTR        posix vms    A signal interrupted send() before any d
 ENETDOWN     posix vms    The local network interface used to reac
 ENETUNREACH  posix vms    No route to the network is present.     
 EWOULDBLOCK  posix vms    The socket's file descriptor is marked O

Yes, generic network failures should be subject to timeouts, not
automatically fail.  No reason not to wait for a router to reboot.  

--jkl