I’m trying to wrap some existing APM calls (BeginX, EndX) in Tasks to get all the nice benefits of them. Unfortunately, our methods are unconventional and use out parameters and so can’t use the standard FromAsync method where you give it both the begin and end delegates and let it wrap it nicely.
This article describes the alternative: an overload that takes an IAsyncResult and only requires you to implement the end callback. They take the IAsyncResult handle, then wait until it completes, then call the delegate you passed in.
This seemed fine, but then I read another article about wrapping APM calls in tasks. He also mentions that the IAsyncResult overload is not as efficient as the other methods. It seems to me like this means that the callback is not used to report completion of the method. That means they must be using the AsyncWaitHandle or polling IsCompleted. Which one do they use? How much performance penalty is it?
If it’s doing polling that means the callback might not come right away and they have to busily check it during the whole call. If they’ve got an AsyncWaitHandle, they have another thread sitting and waiting on the result, which completely defeats the point of using an asynchronous method for me.
Does anyone know what they’re doing and how severe this performance penalty is?
It’s not incredibly severe, but there is more overhead. Since you aren’t providing them the same information (only the
IAsyncResult), the implementation has to call ThreadPool.RegisterWaitForSingleObject to trigger a callback when theIAsyncResultcompletes.When this isn’t used, and the Begin/End pair + callback exist, the callback automatically can trigger the completion of the task, eliminating the extra wait call here. This effectively ties up a ThreadPool thread to block (WaitOne) on the wait handle until the operation completes. If this is a rare occurrence, the performance overhead is probably negligible, but if you’re doing this a lot, it could be problematic.