fix to util_sock.c

[Andrew Tridgell]

> > yep, we switched to recv() in the head branch in May 99 and found that
> > recv() is completely broken on Solaris 2.5. We switched back in
> > November 99.
> 
> 	Is this still true, and what was the problem so I can
> 	see if we think it's fixed?

As far as I know it was fixed in Solaris 2.6.

> 	I have a bug report fixed in '94  that EPIPE might not 
> 	be delivered, causing the machine to spin forever, and
> 	another about disconnected sockets misbehaving in 2.5.1
> 	I wonder if it the bug is one we fixed in a later release.

As far as I remember it wasn't just a "bug". The recv() function just
didn't work at all - I suspect it was implemented like this:

int recv() {
    return 0;
}

Unfortunately Sun seems to do have done this sort of thing more than
once. There was a similar problem with fnmatch() in early versions of
Solaris - it _always_ returned 0. Thank goodness for autoconf.

Anyway, as far as recv()/read() I think we don't change to using
recv() unless there is solid evidence that changing to recv() actually
gains a significant performance advantage. 

There is even reason to believe that recv() with MSG_WAITALL will
actually be slower than read() in some circumstances - think about
what might happen to the TCP receive window with a MSG_WAITALL on 64k
of data. An increased likelyhood of TCP stalls is very plausible,
although I have not done a test to see if this happens.

While it is certainly true that recv() can lead to fewer system calls,
in a program that is using a significant portion of a systems memory
bandwidth the number of system calls is not a good guide to
performance. Using recv() with MSG_WAITALL on large reads could easily
decrease the amount of parallelism in the TCP path as the copy to user
space (which is sometimes a very significant cost) won't begin until
after the whole data load has arrived.

If someone really wants to investigate this then I suggest they modify
tbench to try the proposed strategy and post results. By using the
tbench harness we will be able to eliminate many of the complicated
factors that affect overall performance of a SMB server and
concentrate on the TCP usage only. See the dbench CVS module on
cvs.samba.org for a copy of tbench.

Cheers, Tridge