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

Поиск
Список
Период
Сортировка
От Denis Perchine
Тема Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Дата
Msg-id 3314645575.20000705213418@perchine.com
обсуждение исходный текст
Ответ на Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (kuznet@ms2.inr.ac.ru)
Ответы Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (kuznet@ms2.inr.ac.ru)
Список pgsql-hackers
Hello kuznet,

Wednesday, July 05, 2000, 7:06:06 PM, you wrote:

kmiar> Hello!

>> As I recall, the original complaint was precisely that Linux discards
>> the server->client data instead of allowing the client to read it.  This
>> was on a single machine, so there's no issue of whether it got lost in
>> the network.

kmiar> I am sorry. I have already said: it is not truth.

kmiar> Original reporter (Denis) blamed particularly on the fact,
kmiar> that Linux allows to read all queued data until EOF.
kmiar> Try yourself, if you do not believe.

kmiar> Unfortunately, I deleted that his mail, but you can find it
kmiar> in mail archives I think, it was to netdev or to linux-kernel.

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.

-- 
Best regards,Denis                            mailto:dyp@perchine.com




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: pg_dump and LOs (another proposal)
Следующее
От: JanWieck@t-online.de (Jan Wieck)
Дата:
Сообщение: update on TOAST status