Date: Fri, 25 Apr 2003 03:03:22 -0500 (CDT) From: William Michael Grim <wgrim@siue.edu> To: freebsd-hackers@freebsd.org Subject: Re: recv() returning 0 and EINTR on a still connection. Message-ID: <Pine.SO4.4.05.10304250301320.24952-100000@cougar.isg.siue.edu> In-Reply-To: <20030425.005750.43494308.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't have the first message you sent out anymore. What actually happens when read() reaches EOF is that its file pointer stays at EOF. It doesn't actually close the file descriptor; you can juse as easily fseek to the BOF and read() again. I don't have the code from the first email, but wasn't he using recv() there? I suppose I could be mistaken on what he used. William Michael Grim Student, Southern Illinois University at Edwardsville Unix System Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: wgrim@siue.edu On Fri, 25 Apr 2003, M. Warner Losh wrote: > In message: <Pine.SO4.4.05.10304250110450.18123-100000@cougar.isg.siue.edu> > William Michael Grim <wgrim@siue.edu> writes: > : I think your problem is that n==0 does NOT mean the connection was closed > : (at least not with TCP; I haven't really looked into other session > : protocols). > > I know that it does with FreeBSD, at least for read(2). > > : If n==0, it only means you have stopped receiving data because there is no > : more to be received; you can only trust errno if n==-1 or whatever the man > : page specifies for your OS (FreeBSD is -1 in this case). > > FreeBSD returns -1 and EWOULDBLOCK in this case. > > Warner >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SO4.4.05.10304250301320.24952-100000>