Annotated edit history of
EPROTO version 2, including all changes.
View license author blame.
| Rev |
Author |
# |
Line |
| 1 |
PerryLorier |
1 |
!!!Protocol Error |
| |
|
2 |
|
| |
|
3 |
shamelessly stolen from comp.unix.programmer unix-socket-faq: |
| |
|
4 |
|
| 2 |
PerryLorier |
5 |
2.10. Why do I get EPROTO from read(2)? |
| 1 |
PerryLorier |
6 |
|
| |
|
7 |
From Steve Rago (sar@plc.com): |
| |
|
8 |
|
| |
|
9 |
EPROTO means that the protocol encountered an unrecoverable error for |
| |
|
10 |
that endpoint. EPROTO is one of those catch-all error codes used by |
| |
|
11 |
STREAMS-based drivers when a better code isn't available. |
| |
|
12 |
|
| |
|
13 |
And an addition note from Andrew (andrew@erlenstar.demon.co.uk): |
| |
|
14 |
|
| 2 |
PerryLorier |
15 |
Not quite to do with EPROTO from read(2), but I found out once that on |
| 1 |
PerryLorier |
16 |
some STREAMS-based implementations, EPROTO could be returned by |
| 2 |
PerryLorier |
17 |
accept(2) if the incoming connection was reset before the accept |
| 1 |
PerryLorier |
18 |
completes. |
| |
|
19 |
|
| |
|
20 |
On some other implementations, accept seemed to be capable of blocking |
| 2 |
PerryLorier |
21 |
if this occured. This is important, since if select(2) said the |
| 1 |
PerryLorier |
22 |
listening socket was readable, then you would normally expect not to |
| 2 |
PerryLorier |
23 |
block in the accept(2) call. The fix is, of course, to set nonblocking |
| |
|
24 |
mode on the listening socket if you are going to use select(2) on it. |
