This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Montag, 14. April 2003 11:58, Nick Garnett wrote:
Andrew Lunn <andrew dot lunn at ascom dot ch> writes:
[ferror() on sockets]
A socket is a stream, so this should work.
But only if you have used fdopen() to convert a file descriptor into a stdio FILE object. That's relatively rare for sockets.
Why should an operation been needed? When the socket is closed because of a timeout or the peer, i would expect the local end to be closed and -EPIPE or something similar set in the error indicator. I've not tried this, so i could be totally wrong.
There's no mechanism for signalling events in the TCP/IP stack back up to the stdio library. The only way that you can see that something has happened asynchronously is to call down into the stack and get a error code back. If no such call has been made, the FILE stream will be oblivious of any changes.
What about SIGPIPE? But I think it is not implemented in the stacks.
But my problem seems to be more general, because the host which wants to close the connection, don't send any packet, although any FINISH packet to the board running eCos. So the TCP-stack of eCos can't notice that the host wants to close the connection.
Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --[ "You can complain because roses have thorns, or you ]-- --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
-- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |