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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Дата
Msg-id 3576.962819442@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Denis Perchine <dyp@perchine.com>)
Список pgsql-hackers
Denis Perchine <dyp@perchine.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: zlib for pg_dump
Следующее
От: Jeffery Collins
Дата:
Сообщение: Re: update on TOAST status