NIO.2 and GC activity

[Alan Bateman]

Leon Finker wrote:
> I realized after I sent previous email maybe this is not cross platform so
> it 
> may not be feasible. It is fully supported on windows. Yes I'm referring to 
> buffer(s) always being available to the driver. The goal is to try and
> saturate 
> driver with outstanding read buffers (to a limit of course) to minimize any 
> buffering on its side. The buffering in driver will in most cases happen
> while 
> NIO.2 hands off the read buffer and application does some simplistic
> processing 
> on it. With more than one outstanding read buffer, this can be minimized.
Yes, I'm familiar with it but it's a bit more complicated in that it 
requires a guarantee on the ordering that the I/O operations are 
executed and also requires the application to be able to deal with 
concurrent or even out of order notifications. There are a couple of 
cases where the ordering can't be guaranteed. For example, I/O 
operations are never initiated directly by non-pooled threads (because 
the thread may terminate causing any outstanding I/O operations it 
initiated to abort; this is Windows kernel thing). This and other cases 
means that it is possible for multiple reads on the same channel to be 
initiated in the kernel in a different order than might be expected, 
making it impossible to re-sequence the completion notifications. 
Furthermore, it just doesn't make sense for write operations - for 
example a write may complete without writing all bytes, in which case a 
queued write would corrupt the stream. I'm not against queuing of reads 
on streams but it just may be too advanced for many developers and 
creates the potential for some nasty bugs. Maybe in the future it is 
something to add, as an opt-in rather than the default. In any case, it 
would be interesting to compare the performance against code that 
initiates a read early in the completion handler.

-Alan.