On Mon, 2005-05-09 at 17:12 +0000, Aaron Stone wrote: > I wonder if the bug reporter's LMTP is sitting in a loop waiting for > feof() on the socket and not reading anything. That would certainly cause > LMTP to hang following the last error message he reported. I thought that > sockets do report EOF when they are open, but no more data to be read. > Right?
Saying EOF is confusing. EOF is a concept of POSIX.1 and not unix. This is all confusing. In an attempt to clarify: * read() returns 0 bytes when a pipe has no writers * read() returns 0 bytes from a tty when VEOF was sent to the tty driver * read() returns 0 bytes when at the end of a ifile (not a FILE*) * read/recv() returns 0 bytes from a STREAM SOCKET when SHUT_WR occurs on far end. the "eof" flag of a FILE* is set, _ON_UNIX_ when the underlying read() returned 0. Obviously, this can happen for lots of reasons, none of which (except maybe the kernel ifile) mean no more data is coming... feof() is true on POSIX.1 when the next fread() or fgets() will be unable to return any bytes. Some C libraries will anticipate this with a fstat() or similar, but quite obviously, with sockets, it can't be done this way. The difference is critical, because feof() won't fire until after fread () or fgets() fails when the FILE* is actually on a socket. This is in direct opposition to what POSIX.1 says should happen. Unless the far side is deliberately doing a shutdown(fileno(f),SHUT_WR) you simply are never going to get your "EOF report" on a socket. ... whether it's in the UNIX domain or in another domain... And to make matters worse, NOBODY uses shutdown()*. Not that'd matter if they did... * I mean, _I_ do, but I'm a pedantic bastard :) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
