NIO.2 and GC activity

[Salter, Thomas A]

I couldn't find any MSDN reference that guarantees the order in which multiple pending receives would complete.  Do they promise to satisfy requests in the order they are issued?  Do they guarantee to post completion status in the order the data is received?  I would certainly want to see this spelled out in Windows documentation before writing an application that depended on a particular order.  The cited MSDN Magazine article is 9 years and 2 OS releases old and it only makes a passing reference to multiple pending receives with no guidance on how to order the data.



-----Original Message-----
From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
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.

> 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.