What is the problem this framework intends to solve?

Dec 8, 2013 at 5:07 PM
It appears that this code intends to dispatch messages while waiting for an async operation to complete, I assume with the goal to make the application responsive. This is not necessary from background threads. In general it is very problematic as it creates a nested message loop that allow reentrancy that threatens program stability. And now in Win 8.1 is not allowed. This also seems unneeded on UI threads in the contexts of unit test execution (no need for responsive programs).

Do I understand the purpose of this properly or is there something else this is achieving?

I recommend simply removing the message dispatching and calling task<T>.get() to block until the result is produced.

Chris
Dec 8, 2013 at 5:15 PM
Edited Dec 8, 2013 at 5:45 PM
I see now... This frameworks goal is to enable executing Async methods synchronously in the context of a unit test and an ASTA.

ppl will throw if you call get() from the UI thread before the result is available (async op has completed)

so when run on the UI thread something is needed to manage this. Just waiting on the event produces a deadlock as the async callback needs to be allowed back to the waiting thread, CoWaitForMultipleObjects() allows that but this is not in the modern SDK.
Dec 14, 2013 at 7:02 PM
I have a fix... requested access to the project so I can make that fix.