NIO.2 and GC activity

[Leon Finker]

I should have made the last sentence a question because I didn't know the
implementation. (i.e.: But doesn't this apply to current NIO.2
implementation even with non simultaneous reads?) Sorry about that. Thanks
for the answer!

(the paragraph below only applies if multiple simultaneous reads on same
socket are allowed)
Just one final note, even if reads were not queued to completion port for
non pooled thread and different groups didn't initiate the reads, there
would still be an ordering issue to deal with. If one called WSARecv() N
times in succession for the same socket, they are guaranteed to complete in
the order we submitted them. However, undefined ordering is introduced when
completion notifications are actually done (due to regular thread
scheduling) because N number of threads are servicing the completion port.
So, one would have to deal with out of order issues anyway. Thanks for your
answers!

-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Friday, April 17, 2009 4:05 AM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

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.