Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Denis Perchine <dyp(at)perchine(dot)com>
Cc: kuznet(at)ms2(dot)inr(dot)ac(dot)ru, alan(at)lxorguk(dot)ukuu(dot)org(dot)uk, pgsql-hackers(at)postgresql(dot)org, davem(at)redhat(dot)com
Subject: Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date: 2000-07-05 17:50:42
Message-ID: 3576.962819442@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Denis Perchine <dyp(at)perchine(dot)com> writes:
> I blamed that: Linux gives you EPIPE when you call recv before all
> data available is retrieved. If you will try to read AFTER error you
> will get all data. Problem is that it makes handling very complicated.
> In the case of EPIPE you should try to read again. The problem is that
> you should always try only once.

Ah, thanks for the correction. Now, should we really program around
this behavior of the Linux kernel? I cannot think of any other OS where
it is appropriate to retry on an EPIPE error condition, nor does it make
any sense to do so given the normal meaning of that error code. "Retry,
but only once" is even sillier.

I still think this behavior is a bug, not a feature. If you want to
issue EPIPE (or more likely ECONNRESET) *after* all available data has
been read, that's fine, and EPIPE for subsequent send attempts makes
sense too. But EPIPE on read when there is more data available is just
plain bizarre.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message kuznet 2000-07-05 18:00:52 Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Previous Message The Hermit Hacker 2000-07-05 17:44:27 Re: zlib for pg_dump