This is another question, but here is the answer.
Because sometimes they are situations happend when you cannot rely on the
assumption that client will react on you server's request to close the socket.
In the case of PostgreSQL it was the situation when server should die immediatly.
This happend when you do shutdown or when part of the shared memory is corrupted
and futher work will lead to data inconsistency. In such cases server writes the reason to
socket and closes connection.
There's the following behavior seen on other platforms:
1. Just allow to read all data which was send before connection close, then
return 0. Similar to EOF.
2. Allow to read all data and then return ECONNRESET.
As far as I can understand correct behavior is (1). At least in Socket FAQ it is stated
that programming logic which will assume closed by other side connection means
'QUIT' on the protocol level is acceptable.
Also such kernel behavior leads to the situation like this:
Client send: 'quit'
Server replies 'OK Bye!' and closed connection.
And on the client side I get EPIPE and sometimes full reply, sometimes
only part of it, or nothing.
> > But I still do not hear the voice of the people who maintain this part of the kernel...
>
> You assuming there are such person :-) It's wrong assumation. AFAIK it was
> written by Alan Cox and last who played with is was Andrea Arcangeli so there
> are no special maintainer for that code...
:-((((
-- Sincerely Yours, Denis Perchine---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/