Annotated edit history of
EPROTO version 2 showing authors affecting page license.
View with all changes included.
Rev |
Author |
# |
Line |
1 |
PerryLorier |
1 |
!!!Protocol Error |
|
|
2 |
|
|
|
3 |
shamelessly stolen from comp.unix.programmer unix-socket-faq: |
|
|
4 |
|
|
|
5 |
2.10. Why do I get EPROTO from read(2)? |
|
|
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 |
|
|
|
15 |
Not quite to do with EPROTO from read(2), but I found out once that on |
|
|
16 |
some STREAMS-based implementations, EPROTO could be returned by |
|
|
17 |
accept(2) if the incoming connection was reset before the accept |
|
|
18 |
completes. |
|
|
19 |
|
|
|
20 |
On some other implementations, accept seemed to be capable of blocking |
|
|
21 |
if this occured. This is important, since if select(2) said the |
|
|
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. |