On Sun, Jan 3, 2016 at 3:01 AM, Andres Freund <and...@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) */
for (n = 0; n < 5; n++)
{
..
}
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
