NIO.2 and GC activity

[Alan Bateman]

Leon Finker wrote:
> This can be optional. Current enforced requirement removes possible
> optimizations for receive that developers can do. I worked on communication
> layer that did benefit from multiple outstanding recvs. I don't have all the
> reference available, but here is one I could find quickly
> http://msdn.microsoft.com/en-us/magazine/cc302334.aspx
> "as long as the application takes care to always have a few overlapped
> WSARecvs outstanding on a connection. The availability of posted application
> buffers removes the need for AFD to buffer incoming data."
>
> In short more than one receive can be an optimization where data will not be
> buffered in tcp stack, but written directly to application buffer (more
> optimizations in win2k8 and up including NIC writing directly to memory
> where application buffer is http://support.microsoft.com/kb/951037). So what
> if one has to deal with not so complicated re-sequencing logic? The core of
> communication layer code is written and tested once. It doesn't change
> often. I personally vote against this enforcement. It can be enabled for
> debug or made optional.
>   
Just so we're clear, you can initiate another read operation in your 
completion handler (it doesn't t require the completion handler to 
complete). The optimization that I think you are referring to just 
requires that there is a buffer available for an outstanding read so 
that it can read directly into the buffer. That should work fine and 
only rarely (protocol dependent and buffer size dependent of course) 
should the driver need to buffer.

-Alan.