problem with write() to a socket and EPIPE

problem with write() to a socket and EPIPE

[oliver.kowalke]

Hello,

I've the following problem.
If the peer has closed its socket connection the second write to this 
socket should return -1 and errno should be set to EPIPE (if SIGPIPE is 
set  
to be ignored). This never happens with my code. Why?

OS: Linux (Debian 2.2r3)
kernel: 2.4.4
compiler: gcc-2.95.2
c-lib: libc-2.1.3

with best regards,
Oliver

(writen() is a member function of my socket C++-class)

ssize_t
sock::writen( const void * vptr, size_t n)
{
        size_t          nleft;
        ssize_t         nwritten;
        const char      *ptr;

        ptr = static_cast< char * >( vptr);
        nleft = n;

        struct sigaction new_sa;
        struct sigaction old_sa;
        
        new_sa.sa_handler = SIG_IGN;
        ::sigemptyset( & new_sa.sa_mask);
        new_sa.sa_flags = 0;
        ::sigaction( SIGPIPE, & new_sa, & old_sa);              

        while ( nleft > 0)
        {
                if ( ( nwritten = ::write( m_handle, ptr, nleft) ) <= 
0) 
                {
                        if ( errno == EINTR)

                                nwritten = 0;           /* and call 
write() again */ 

                        else if ( errno == EPIPE)

                                return EOF;             /* write to 
socket with no readers */ 

                        else

                                throw net_io_ex( ::strerror( errno), 
"writen()", __FILE__);     /* error */ 

                }

                nleft -= nwritten;
                ptr   += nwritten;
        }
        /* set to its previous action */
        ::sigaction( SIGPIPE, & old_sa, 0);

        return n;
}

Re: problem with write() to a socket and EPIPE

[Richard B. Johnson]

On Mon, 18 Jun 2001 oliver.kowalke@t-online.de wrote:

> Hello,
> 
> I've the following problem.
> If the peer has closed its socket connection the second write to this 
> socket should return -1 and errno should be set to EPIPE (if SIGPIPE is 
> set  
> to be ignored). This never happens with my code. Why?
> 

So what errno does it return? Writing to a closed socket can
return several things, based upon what was detected first. I
don't think you can count on a specific errno value. Successful
socket handlers use the following heuristics:

If the returned value was -1, the error is temporary, try again.
If the returned value was 0, the error is permanent.

The first write to a closed socket may return -1, with an errno
of something representative of local buffers being full. It takes
some time for a FIN or a RST to show up as the reason why there
is so much data queued. So, if you follow the above heuristic,
the last reason why you got the previous errors will likely be
what you expect.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.