Performance cost of using the IAsyncResult overload of Task.FromAsync

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 usi开发者_如何学JAVAng 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?

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 the IAsyncResult completes.

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.

Looking at the code in JustDecompile, it creates a TaskCompletionSource wrapping the IAsyncObject, which creates a new Task, which probably means a thread waiting for the IAsyncObject to complete. Not ideal, but it's probably the only way to do it since there is no way to make a good one-size-fits-all polling rate.

When you pass in a ISyncResult there is no way for TaskFactory to insert a callback back. So the TaskFactory needs the ISynResult spin up a WaitHandle, and needs the ThreadPool to get a thread to wait on this handle. There is no polling involved.

Arrived here because I had a similar problem (with out parameters), but only on the End method. This is what I came up with, it might be helpful to someone:

var provider = new Provider();
return Task<Whatever>.Factory.FromAsync(provider.Begin, ar =>
{
    Whatever outparam;
    provider.End(out outparam);
    return outparam;
}, state);

It compiles :)