On Wed, Sep 06, 2023 at 09:28:31AM -0400, Mouse wrote:
> > 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.
thanks. I remplaced the read with a poll()/read() loop; this fixes the issue.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
