On Sun, Jan 3, 2016 at 3:01 AM, Andres Freund <andres@anarazel.de> wrote: > On 2016-01-02 22:25:31 +0100, Brar Piening wrote: > > Andres Freund wrote: > > >That seems like a pretty straight forward bug. But it hinges on the > > >client side calling shutdown() on the socket. I don't know enough about > > >.net's internals to judge wether it does so. I've traced things far > > >enough to find > > >"Disposing a Stream object flushes any buffered data, and essentially > > >calls the Flush method for you. Dispose also releases operating system > > >resources such as file handles, network connections, or memory used for > > >any internal buffering. The BufferedStream class provides the capability > > >of wrapping a buffered stream around another stream in order to improve > > >read and write performance." > > >https://msdn.microsoft.com/en-us/library/system.io.stream%28v=vs.110%29.aspx > > > > > >which'd plausibly use shutdown(). > > > > In the new days of Microsoft you can confirm that even more... > > http://referencesource.microsoft.com/#System/net/System/Net/Sockets/Socket.cs,6245 > > Thanks for digging thatup! > > Indeed it does use shutdown(). If I read the npgsql code that'll even be > done in the exception handling path. So fixing the 0 byte case might > already do the trick. >
I think this true for a TCP socket, but this code-path is used for UDP
(SOCK_DGRAM) sockets as well and there is a comment below in
that function which seems to be indicating why originally 0 byte case
has not been handled at the place suggested by you (now it seems to
be much less relevant).
pgwin32_recv()
{
..
/* No error, zero bytes (win2000+) or error+WSAEWOULDBLOCK (<=nt4) */