6 ms·

I appreciate the original comment by ikekkdcjkfke, and your elaboration, gpderetta. However, I perceive a distinction between compiler optimization and proposin

by peheje 3y ago

I appreciate the original comment by ikekkdcjkfke, and your elaboration, gpderetta. However, I perceive a distinction between compiler optimization and proposing a fundamentally different model for handling asynchronicity. It seems to me that what you're suggesting deviates significantly from the existing C# model. Transitioning to this model wouldn't be a simple matter of compiler optimization—it would be a major breaking change that would require rethinking many aspects of the language. Please don't misunderstand me; I'm not dismissing your proposal outright. However, it's essential to consider the potential trade-offs such as control flow management and error handling strategies. These are currently well-addressed by the async mechanism in C#. Regarding polymorphic async-ness, I acknowledge this as a minor limitation within the current C# model. However, a common practice involves returning Task or Task<T>, even when no async calls are involved. Moreover, I find Kotlin's approach to handling this through inlining of suspend functions quite intriguing. You can check it out here: https://kotlinlang.org/docs/kotlin-tips.html#the-suspend-and-inline-mystery https://kotlinlang.org/docs/kotlin-tips.html#the-suspend-and... In closing, it would be beneficial to our discussion if we could clarify whether we're contemplating an optimization within the current C# framework or proposing a fundamentally different approach to asynchronicity.

gpderetta 3y ago
I'm not suggesting that C# makes a change, it is probably too late (although you could easily implement both models), I was just describing my preferred semantics (well, I prefer stackfull coroutines, but that's another story). I don't think it deviates much from the existing semantics, the minimum change is adding awaits automatically for any call to awaitable functions and requiring async annotations otherwise. This is a relatively minor change. I don't think that the async/sync division is a minor thing, but thanks for the Kotlin reference, I'll take a look. Before watching the video I guess that they implement 'stackfull-like' behaviour in otherwise stackless coroutines by force-inlining any HOF so that the coroutine is again flattened. If that's the case, that's great! What happens if inlining can't happen? They reject the code or convert to stackfull coroutines? That's for me as always been the holy grail: stackfull semantics that optimize to stackless (i.e. bounded stack usage) when possible (i.e. when the compler can see all possible yield points). I have been trying to figure out (in C++) the subset of the language such as the optimization is always guaranteed (at the very least you need first class and explicit continuations so that the compiler can track them and inlining must be possible). Possibly Kotlin has cracked it.
ikekkdcjkfke 3y ago
To clarify what I was trying to argue for, if one is using the .net async Task system only for the purpose to help the thread pool (always immediately awaiting an async method) then the responsibility should bear more on the .net framework, instead of spilling async/await Task<> into code bases. I don't know what a solution looks like, but maybe just threads are too expensive in .net

by peheje 3y ago

gpderetta 3y ago

I'm not suggesting that C# makes a change, it is probably too late (although you could easily implement both models), I was just describing my preferred semantics (well, I prefer stackfull coroutines, but that's another story). I don't think it deviates much from the existing semantics, the minimum change is adding awaits automatically for any call to awaitable functions and requiring async annotations otherwise. This is a relatively minor change. I don't think that the async/sync division is a minor thing, but thanks for the Kotlin reference, I'll take a look. Before watching the video I guess that they implement 'stackfull-like' behaviour in otherwise stackless coroutines by force-inlining any HOF so that the coroutine is again flattened. If that's the case, that's great! What happens if inlining can't happen? They reject the code or convert to stackfull coroutines? That's for me as always been the holy grail: stackfull semantics that optimize to stackless (i.e. bounded stack usage) when possible (i.e. when the compler can see all possible yield points). I have been trying to figure out (in C++) the subset of the language such as the optimization is always guaranteed (at the very least you need first class and explicit continuations so that the compiler can track them and inlining must be possible). Possibly Kotlin has cracked it.

ikekkdcjkfke 3y ago

To clarify what I was trying to argue for, if one is using the .net async Task system only for the purpose to help the thread pool (always immediately awaiting an async method) then the responsibility should bear more on the .net framework, instead of spilling async/await Task<> into code bases. I don't know what a solution looks like, but maybe just threads are too expensive in .net