Discussion: Unavailability from asynchronous contexts

[etcwilde (Evan Wilde)]

@George

I've been thinking about this very issue but from a slightly different perspective: blocking APIs. These aren't quite as explicitly problematic as thread-local-accessing-APIs, but can still result in very subtle failures, ranging from performance degradation to resource starvation. I'd bet this is the reason NIO provides NonblockingFileIO , which allows you to schedule totally-could-block API calls on their own threads, thus leaving the primary event loops available for "true" nonblocking async code. My guess is it will be really common for folks to accidentally call subtly blocking APIs from async contexts without a mechanism such as this. @beccadax's suggestions of renamed: seems like an important part of the solution (especially for APIs without similarly-spelt async overloads).

I've been mulling this comment over for a while now. I'm still not quite convinced that blocking calls are necessarily something you want to ban from asynchronous contexts. It seems like you would be to wrap the blocking call in a detached task/async-let to avoid blocking the current task if that is necessary. Am I missing something? There is a subtle undertone of the goals of the completionHandlerAsync attribute; [Pitch] @completionHandlerAsync attribute. Right now that only works on functions that have an escaping closure. I wonder if that could be generalized a bit more for the warning case?