NIO.2 and GC activity

[Alan Bateman]

Leon Finker wrote:
> I agree there is no advantage for the writes, and I don't advocate it. On
> the reads I disagree that the order can't be guaranteed or re-sequenced on
> completion/failure. One is always able to re-establish the original order of
> reads that were scheduled on their completion or failure simply by
> associating the counter with the scheduled reads and then re-establishing
> the sequence. Yes, one has to be aware that if they schedule a read on non
> I/O windows pool thread and thread immediately exits, the I/O request will
> be canceled. But this applies to current NIO.2 implementation even with non
> simultaneous reads. 
Our implementation never initiates I/O operations on non-pooled threads. 
Instead, if a non-pooled thread invokes read/write it will be queued 
(via a message posted to the completion port) so that it is initiated on 
a pooled thread. That is where the ordering becomes undefined. Another 
case is where a pool thread associated with one group initiates an I/O 
operation on a channel associated with a different group.

> I agree the code is somewhat involved, and one has to
> deal with concurrency, but it's an option for core communication framework
> libraries out there. This optimization is not for every case, it's for
> specific communication/protocol patterns. So, I'm not sure if comparison
> will be fair. It's just a suggestion based on experience. If there is no
> need for this from the community, then you're right it can be added later.
>   
Yes, this is something for later once people have more experience using 
the API.

-Alan.