Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
В списке pgsql-hackers по дате отправления:
| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера