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

From: Denis Perchine <dyp(at)perchine(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date: 2000-06-27 16:12:59
Message-ID: 00062723152607.00490@dyp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ms2(dot)inr(dot)ac(dot)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(at)perchine(dot)com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-06-27 17:40:25 Re: AW: Proposal: More flexible backup/restore via pg_dump
Previous Message Tom Lane 2000-06-27 15:23:05 Re: AW: Proposal: More flexible backup/restore via pg_dump