Re: short reads on unix stream on netbsd-10

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B