Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection - Mailing list pgsql-hackers

From Denis Perchine
Subject Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date
Msg-id 00062723152607.00490@dyp
Whole thread Raw
Responses Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello all,

This is the result of my 6 days "war" with Linux kernel people...
Any usefull comments on this????

----------  Forwarded Message  ----------
Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date: Tue, 27 Jun 2000 16:21:55 +0400 (MSK DST)
From: kuznet@ms2.inr.ac.ru

Hello!

> Sorry... But seems that you did not understand the problem.
> I talk about recv... Not write... write SHOULD give EPIPE on connection reset...
> But not recv/read.

I did understand. This error was for write(), but it became known
_after_ you exited write(). So that it is delivered to read().
It is usual problem of all full-duplex pipes.

We could translate this EPIPE to ECONNRESET, when it is delivered
to read(), but it does not change its sense.

Solaris does not translate.


> Usual way of handling connection reset when you do only read is to give
> all data available and then return 0, indicating EOF.

Sorry? Think a bit.

You wrote to dead socket, right? It is the hardest error.
If the transport were local, you would get SIGPIPE and died painful death.
If an OS ignores such events, it is simply impossible to use,
you will get silently truncated data all the time.


> Or some OSes (HPUX if I'm not mistaken) gives you all data available and then
> ECONNRESET. But not other way around...

This approach has its merits, and it is acceptable in principle.

But Linux approach is evidently better, because errors are expedited.
Each protocol, where out of band events are inlined to data
is inclined to deadlocks.

In Linux scheme you know forward that stream is aborted.
Depending on protocol you may choose to abort protocol
or to continue to operate, parsing already received messages.


>         But not other way around...

You have just seen a new way around. The correct one. 8)

Alexey
-------------------------------------------------------

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------


pgsql-hackers by date:

Previous
From: Michael Fraley
Date:
Subject: Please help cache lookup failed
Next
From: Philip Warner
Date:
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump