Differences between current version and previous revision of EPROTO.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Monday, July 14, 2003 4:11:04 pm | by PerryLorier | |
| Older page: | version 1 | Last edited on Monday, July 14, 2003 4:10:41 pm | by PerryLorier | Revert |
@@ -1,9 +1,9 @@
!!!Protocol Error
shamelessly stolen from comp.unix.programmer unix-socket-faq:
-2.10. Why do I get EPROTO from read()?
+2.10. Why do I get EPROTO from read(2
)?
From Steve Rago (sar@plc.com):
EPROTO means that the protocol encountered an unrecoverable error for
@@ -11,16 +11,14 @@
STREAMS-based drivers when a better code isn't available.
And an addition note from Andrew (andrew@erlenstar.demon.co.uk):
- Not quite to do with EPROTO from read(), but I found out once that on
+ Not quite to do with EPROTO from read(2
), but I found out once that on
some STREAMS-based implementations, EPROTO could be returned by
- accept() if the incoming connection was reset before the accept
+ accept(2
) if the incoming connection was reset before the accept
completes.
On some other implementations, accept seemed to be capable of blocking
- if this occured. This is important, since if select() said the
+ if this occured. This is important, since if select(2
) said the
listening socket was readable, then you would normally expect not to
- block in the accept() call. The fix is, of course, to set nonblocking
- mode on the listening socket if you are going to use select() on it.
-
- 2.11. How can I force a socket to send the data in its buffer?
+ block in the accept(2
) call. The fix is, of course, to set nonblocking
+ mode on the listening socket if you are going to use select(2
) on it.
