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/