Subject: Re: Sensing a disconnected socket
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Rick Byers <rickb@iaw.on.ca>
List: current-users
Date: 06/25/1997 18:21:23
On Wed, 25 Jun 1997, der Mouse wrote:

> > 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...

Basically, I'm using read on a DIFFERENT socket (it's connected to a
server - it won't get closed), and I don't want to use non-blocking (too
much hasle for such a little thing).  So I just block on read from the
server, but have a 1 second timer that checks the HTTP socket to make sure
it hasn't been closed.  We don't want to listen to the server anymore if
the user has hit STOP.  I could just select for read on both sockets every
time I need to read, and then handle apprpriatly, but this is a lot
easier.

> > 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.

I was using fgetc(stdout), it returned -1, and ferror and feof both return
0 afterwards.  No big deal though...

Thanks!
	Rick

=========================================================================
Rick Byers                                      Internet Access Worldwide
rickb@iaw.on.ca                                System Admin, Tech Support
Welland, Ontario, Canada                                    (905)714-1400
http://www.iaw.on.ca/rickb/                         http://www.iaw.on.ca/