This project is read-only.
1
Vote

Methods shouldn't block the main thread on any platform

description

Some of the supported platforms only offer synchronous APIs (Mono, and desktop in particular). When the PCL library's async APIs are called, these remain on their caller's thread to get their work done.

The guidance from the async designers is that you don't implement an async method that does nothing but switch to the threadpool and then works synchronously, as that hides the fact that you're not truly asynchronous and it's something that if the caller wanted to do, they could do that themselves anyway. However in this case the library offers async APIs because some implementations are truly async and should therefore be exposed as such through this API. That just leaves the question of whether the sync implementations should be moved off the caller's thread.

I think we should take this approach: if we're on a threadpool thread, complete synchronously (no artificial thread change). Otherwise switch to the threadpool. In this way, we can be sure that app authors who operate primarily on the UI thread and rely on these async methods to avoid responsiveness issues in their app won't be disappointed. But those who are already on a threadpool thread won't incur an artificial perf or GC pressure hit from our needlessly switching threads again.

comments