Subject: Re: Sensing a disconnected socket
To: Andrew Brown <email@example.com>
From: Rick Byers <firstname.lastname@example.org>
Date: 06/24/1997 11:43:39
On Thu, 19 Jun 1997, Andrew Brown wrote:
> >Ideally the process will exit as soon as the user stops the transfer, but
> >as far as I can tell, no signal (SIGPIPE, SIGURG etc..) is delivered to
> >the process when the socket in intially closed. I can just have a 1
> >second interval alarm to check (and possibly exit) if the socket has been
> >closed. How can I tell that it has been closed? I can't seem to find any
> >functions that will return that information.
> 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. or, selecting on it for writing
> will return instantly (but will result in a sigpipe) after it's been
> closed. then again, this might be a better situation in which to use
> the "exceptfds" which no one has ever been able to tell me what they
> were for...
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), 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.
Interestingly enough, ferror and feof both return 0 after EOF is read
(shouldn't one be true?). Actually, the only difference I could find
whatsoever when the socket is closed is that select returns read ready
(exceptfds don't change).
Thanks a lot,
Rick Byers Internet Access Worldwide
email@example.com System Admin, Tech Support
Welland, Ontario, Canada (905)714-1400