Subject: Re: Sensing a disconnected socket
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/25/1997 10:13:08
>>> Ideally the process will exit as soon as the user stops the
>>> transfer, but [...]
>> if you're only ever writing to the socket and don't expect to ever
>> read from it, then selecting on the socket for reading will return
>> instantly after it's been closed.
True. This may be the best way.
>> or, selecting on it for writing will return instantly (but will
>> result in a sigpipe) after it's been closed.
> I decided to watch the result of a select (with no timeout) on the
> socket. Strangly enough, selecting for write doesn't seem to do
> anything when the socket is closed (doesn't generate SIGPIPE),
I think the person who wrote that was being a little too elliptical.
select() does not generate SIGPIPE; rather, select() should indicate
that the socket is ready for write, and a following write() attempt
actually raises SIGPIPE (and returns EPIPE if SIGPIPE is blocked or
> however, selecting for read does show that data is available (EOF)
> when the socket is closed. So I just setup a 1 second timer that
> allways checks if it can read from the socket (it's normally write
> only), and if it reads an EOF it bails.
I don't see the need for the timer, but shrug...
> Interestingly enough, ferror and feof both return 0 after EOF is read
> (shouldn't one be true?).
ferror and feof work on stdio streams. select, read, and write work on
file descriptors. There is no stdio analog to select(); I can't even
see one in the NetBSD extensions to standard stdio. If you read EOF
via read(), stdio won't know anything about it.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B