> serv_input: read@3 need 468 got 396 (and disconnects).
> The code is:
> if (i != (nchars = read(fd, T.c, i))) {
> fprintf(stderr, "serv_input: read@%d need %d got %d\n",
> fd, i, nchars);
> server_died();
> }
> fd 3 is a unix stream socket
> I didn't find any place where this file descriptor could have been
> put to nonblocking.
> I could wrap the read in a loop to work around this, but I wonder if
> it's expected behavior to get short reads in this case ?
That's a good question. In general, SOCK_STREAM socket connections
never promise atomicity of anything larger than one byte. It's
possible AF_LOCAL provides a stronger promise, but, if so, I'm not sure
where that promise is documented, or how widespread it is.
As for it being _expected_ behaviour...I wouldn't call it "expected",
exactly, but I would call it "not particularly surprising".
So, I'd say the code you quote is at fault here.
If the fd is _always_ an AF_LOCAL/SOCK_STREAM socket, instead of
writing a loop, you could use recv() with MSG_WAITALL. I use that in a
few places where I want "fill my whole buffer, looping as needed"
semantics; indeed, one relatively common idiom in my code uses an
AF_LOCAL/SOCK_STREAM socketpair instead of a pipe specifically so it
_can_ use MSG_WAITALL. (In that idiom, it's transferring very little
data - zero bytes except in rare error cases - so performance is not an
issue, and it simplifies the code significantly.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
