recv() returning 0 and EINTR on a still connection.

[William Michael Grim]

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 at siue.edu



On Fri, 25 Apr 2003, M. Warner Losh wrote:

> In message: <Pine.SO4.4.05.10304250110450.18123-100000 at cougar.isg.siue.edu>
>             William Michael Grim <wgrim at 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
>