GetQueueCompletionStatusEx

[John Davis]

Forgot the CC

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/adcd3a3b/attachment.html