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
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 |