Fwd: GetQueueCompletionStatusEx

[John Davis]

Alzheimers must be setting in, forgot the CC again ...

---------- Forwarded message ----------
From: John Davis <jdavis at pcprogramming.com>
Date: Thu, Dec 31, 2009 at 11:22 AM
Subject: Re: GetQueueCompletionStatusEx
To: Alan Bateman <Alan.Bateman at sun.com>


This is also noteworthy ...


While you don’t need an event in the Overlapped structure when using
Completion Ports because the event is never waited on, if you leave it out,
the event in the file handle will be set and that incurs extra locking.


http://blogs.technet.com/winserverperformance/archive/2008/06/26/designing-applications-for-high-performance-part-iii.aspx
 On Thu, Dec 31, 2009 at 11:01 AM, John Davis <jdavis at pcprogramming.com>wrote:

> I'm not an expert on the nio internals.  My thinking is it would be nice if
> everything could be done with a single thread (ie all reads/writes on all
> handles are async and pumped thru IOCP).  Because the kernel context switch
> overhead is pretty much eliminated with this call, there is no longer a need
> to have a thread pool to handle the context switch overhead.  We also
> wouldn't have the batching dilema with the thread pool gone.  Only problem
> with this model is that there's no way to guarantee a completion handler
> won't block.
>
> My experience from work is it's fast as hell in straight C++.  Due to
> NDA's, etc. I don't have any benchmarks to show.
> SetFileCompletionNotificationModes, allows the callback to be invoked
> immediately, rather than pumping thru IOCP and thread pool.
>
> On Thu, Dec 31, 2009 at 10:40 AM, Alan Bateman <Alan.Bateman at sun.com>wrote:
>
>> John Davis wrote:
>>
>>> Any plans to add the new 2008 Server API's to nio?
>>>  GetQueuedCompletionStatusEx
>>>
>> Maybe, but it depends on the configuration. With a fixed thread pool then
>> each thread retrieves a completion result and dispatches directly to the
>> completion handler. For that case it would be inconvenient to retrieve
>> completion results in batch. However for a cached or other thread pool then
>> there are 1+ internal threads where each thread retrieves a completion
>> result and submits a task to the thread pool to invoke the completion
>> handler. For that configuration then it may be beneficial (esp. when there
>> is a single internal thread retrieving events) but we would need to measure
>> it before changing the code. Have you done any tests or  do you have
>> performance results that you could share on this one?
>>
>> SetFileIoOverlappedRange
>>>
>> No specific plans at this point because it requires special privileges to
>> lock pages into memory. However if there was some measurable improvement for
>> privileged users then it wouldn't be too difficult to make of use of this as
>> there is already a cache of OVERLAPPED structures per channel (or handle).
>>
>> SetFileCompletionNotificationModes
>>>
>> This one is new (to me anyway). In the implementation we don't use a
>> completion events. If Windows is still setting some internal event and this
>> can be skipped then it could be beneficial. We require a completion result
>> per successful I/O operation so we couldn't use that mode.
>>
>> -Alan.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20091231/a28d294a/attachment.html