ApplicationException always occur while calling DeviceIoControlAsync using same hDevice at 2nd time about vanara HOT 13 CLOSED

ThreadPool.BindToHandle only allows a handle to be bound once per thread. It appears you're trying to reuse the handle held in device in your code. So my question is: Should the library work around the ThreadPool code or are you using DeviceIoControl in a way that is not consistent with its pattern by calling it twice? I'm not familiar enough with that function to answer the question.

from vanara.

Reuse device is common scenes, for example: open a virtual network adapter, and then keep reading and writing in a while loop for redirect or analysis network traffic. If open and close device frequently, it will reduce performance.

Even the example is Read and Write, but this depends on the driver implementation, if it implement by DeviceIoControl ?

from vanara.

This one also is ready for testing

from vanara.

Capturing exceptions can cause some performance degradation.
So, I don't think so BindHandle each call is a good way.

Please see my test result:

This is the last code without my fix, you can see I call DeviceIoControlAsync 100 times, and print it cost time in Milliseconds:

the result:

If I do some fix, only BindHandle at first time, and the test code do not change as above:

the result:

from vanara.

I came up with three compromises.

1. Wrap CreateFile with bool isAsync argument, BindHandle in side CreateFile if isAsync == true. Or check if FileFlagsAndAttributes.FILE_FLAG_OVERLAPPED had set.

2. Exposing bool bindHandle argument for all the paths of DeviceIoControlAsync, but there's too much codes to modify, and it's not very elegant.

3. Remove BindHandle that is inside SetupOverlappedFunction and add checking if the device had bind. Throw an exception tells user need to bind handle manually if not bind. (I don't know if this is feasible)

from vanara.

I had thought about 1 and 3. The problem is that the ThreadPool uses the handle to associate threads so it is not copying handles across thread boundaries. Removing it reduces the threading performance. I can collect handles and check them before calling BindHandle. With that, I only run the risk of holding the handle value until the process terminates. Maybe ThreadPool is already doing this so there is no harm.

from vanara.

Do you means save handles in a static HashSet or Dictionary, and check is it already exist before bind ?

from vanara.

Exactly

from vanara.

It seems feasible.

from vanara.

I just pushed updated code. Let me know if the bug is gone and performance is back.

from vanara.

Works well now.

from vanara.

By the way, are you planning to release version 2.3.0 of the nuget package these days ?

from vanara.

Yes. In the next 2 days.

from vanara.