> > 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.
No.... Don't do it... At least I can write workaround with comment:
Just to make this buggy Linux happy :-((((
> 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)
Now I start to understand why BSD people hate Linux... Due to such
statements. Maybe even this is the correct one, but it breaks programs
that works. And it is different from other OSes which makes the task
of writing portable programs very hard. Only because Linux kernel people
think they are gods.