Hello!
> 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.
Well, to me it does not look very essential, when asynchronous
error returned. Remember about EAGAIN and EINTR yet. You are not confused
with such erros, right? Why? 8)
Seems, this order of issuing errors etc. at read() is specified in posix.
I do not know really. I have said, error reporting only if no data are pending,
looks legal and has its merits. Main thing is not to forget to report error
at all. 8)
[ Alan, seems, all the comments about order of checks while read() are your ones. Can you comment? Maybe, it is really
worthto change.
]
Side note: TLI really does not _allow_ any operations on endpoint
in any direction until asynchronous error condition is cleared.
In fact, Linux does this on BSD sockets as well.
This is really natural, but I agree, it is inconvenient yet.
Alexey
