4 ms·
I was thinking more in terms of making good old 'blocking' calls and that the compiler can 'taskify' those old blocking calls to let the thread do some other ta
by ikekkdcjkfke 3y ago
I was thinking more in terms of making good old 'blocking' calls and that the compiler can 'taskify' those old blocking calls to let the thread do some other task instead of waiting on the 'blocking'
- notamy 3y agoSometimes you want to spawn a [future/task/promise/...] and not immediately await it, but instead pass it around. Suppose something like: should_be_future = async_function() should_execute = async_function() # <--- await goes here handle_future(should_be_future) handle_result(should_execute) While the compiler could figure out where to insert awaits automatically, it adds cognitive overhead for the developer -- suddenly the same way of calling a function can result in either a [future/task/promise/...] or the expected type.
- gpderetta 3y agoThen you should annotate the tricky diverging call site with async (see my other comment), instead of making it implicit and requiring annotation of the common expected case: should_be_future = async async_function() should_execute = async_function() # <--- await goes here handle_future(should_be_future) handle_result(should_execute)
- ikekkdcjkfke 3y agoI just don't run into many cases where I'm not immediately awaiting a task, so instead of littering the code base with async await and their return types all the way up, there could be a lighweight version that free's the thread up when waiting on a blocking call (I'm assuming the main reason we want to use async in C# is to free the thread up to do other tasks). NotAPromiseObject ReadCsv(FileFile file){ string content = waitfor File.ReadAsync(file) ...