4 ms·

> how can you have one runtime that is multi-threaded and one runtime that is not, and expect to be able to seamlessly interchange them? That works fine for C#

> how can you have one runtime that is multi-threaded and one runtime that is not, and expect to be able to seamlessly interchange them? That works fine for C#. When writing UI applications all async code started from the UI thread will continue to run single threaded on the UI thread. Everything else runs multi threaded in a thread pool. No need to change any of the async code to work for either.

xnorswap 3y ago
IIRC C# has management under the hood with different SynchronizationContext [0] to manage this, and it can lead to bad habits like sprinkling "ConfigureAwait(false)" all over code. It's also devilishly hard to understand, I've read a blog [1] on the subject several times and don't always fully grasp the consequences of different options. [0] https://learn.microsoft.com/en-us/dotnet/api/system.threading.synchronizationcontext?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.threadin... [1] https://hamidmosalla.com/2018/06/24/what-is-synchronizationcontext/ https://hamidmosalla.com/2018/06/24/what-is-synchronizationc...
pjmlp 3y ago
No it doesn't, hence why there are best practices guidelines written by the .NET architects, and there was a research project to add Go/Java co-routines as well. https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... https://twitter.com/davidfowl/status/1532880744732758018?lang=en https://twitter.com/davidfowl/status/1532880744732758018?lan... https://github.com/dotnet/runtimelab/issues/2057 https://github.com/dotnet/runtimelab/issues/2057 https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398
- ko27 3y ago
  Yes it does. Those best practices are very easy to follow and are enforced by analyzers. I have never encountered those issues on a recent big project I worked on, although they were common in the past when async was new. Also the green threads research concluded that it's not worth adding it to NET: https://github.com/davidwrighton/runtimelab/blob/report/docs/design/features/greenthreads.md#green-threads-technical-report https://github.com/davidwrighton/runtimelab/blob/report/docs...
  - pjmlp 3y ago
    Ah the usual argument that good programmers never make mistakes. The green threads research (which are those github issues I already linked to) concluded that it's not worth adding it to NET, because basically now it is too late to retrofit them into .NET, without having the issue of yet another way to color code, for little gain overall. I also suggest watching the BUILD 2023 ASP.NET panel on the matter.
    - ko27 3y ago
      > Ah the usual argument that good programmers never make mistakes. Not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening. > because basically now it is too late to retrofit them into .NET Nope, read the conclusion. There are other factors not just backwards compatibility (which isn't even a blocker).
      - pjmlp 3y ago
        > not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening. Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. > Nope, read the conclusion. There are other factors not just backwards compatibility. Again, I wrote the Github issues regarding green threads on my comment, so I don't know, maybe I actually already read them?
        ko27 3y ago
        > Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. The analyzers are part of the build, they work everywhere (command line, VS code). Either way, I am glad we finally agree that async await "works fine" for modern .NET. > so I don't know, maybe I actually already read them? I did, I even responded to your links with the official conclusion from the NET team on those issues. Now maybe your turn to read?
- neonsunset 3y ago
  You keep referencing these articles on async I think it is best that you stop. Some of the advice has been known to cause controversy, nor is necessary to think about in standard line of buisness code.
  - lloydatkinson 3y ago
    100%
  - pjmlp 3y ago
    I am not afraid of controversy.
- 0xDEF 3y ago
  There are reasons Go/Erlang-like lightweight userland threads can be useful even if .Net already has a good async story.
- yyyk 3y ago
  The Java implementation required modifying the IO routines, and this is greatly helped by Java interop being far from easy. .NET was always more friendly to interop, lots of projects would be affected. Fixing this would either be a serious break in the ecosystem, or you'd have a new capacity with way too many asterisks to be useful. The .NET world already spent the budget for big migrations with .NET Framework -> Core (just like Java did with Java 8->9, or Python with 2->3) - as much as we might like green threads, they aren't useful enough (compared to async/await) to justify another break.
deleted 3y ago
[deleted]

xnorswap 3y ago

IIRC C# has management under the hood with different SynchronizationContext [0] to manage this, and it can lead to bad habits like sprinkling "ConfigureAwait(false)" all over code. It's also devilishly hard to understand, I've read a blog [1] on the subject several times and don't always fully grasp the consequences of different options. [0] https://learn.microsoft.com/en-us/dotnet/api/system.threading.synchronizationcontext?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.threadin... [1] https://hamidmosalla.com/2018/06/24/what-is-synchronizationcontext/ https://hamidmosalla.com/2018/06/24/what-is-synchronizationc...

pjmlp 3y ago

No it doesn't, hence why there are best practices guidelines written by the .NET architects, and there was a research project to add Go/Java co-routines as well. https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... https://twitter.com/davidfowl/status/1532880744732758018?lang=en https://twitter.com/davidfowl/status/1532880744732758018?lan... https://github.com/dotnet/runtimelab/issues/2057 https://github.com/dotnet/runtimelab/issues/2057 https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398

ko27 3y ago
Yes it does. Those best practices are very easy to follow and are enforced by analyzers. I have never encountered those issues on a recent big project I worked on, although they were common in the past when async was new. Also the green threads research concluded that it's not worth adding it to NET: https://github.com/davidwrighton/runtimelab/blob/report/docs/design/features/greenthreads.md#green-threads-technical-report https://github.com/davidwrighton/runtimelab/blob/report/docs...
- pjmlp 3y ago
  Ah the usual argument that good programmers never make mistakes. The green threads research (which are those github issues I already linked to) concluded that it's not worth adding it to NET, because basically now it is too late to retrofit them into .NET, without having the issue of yet another way to color code, for little gain overall. I also suggest watching the BUILD 2023 ASP.NET panel on the matter.
  - ko27 3y ago
    > Ah the usual argument that good programmers never make mistakes. Not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening. > because basically now it is too late to retrofit them into .NET Nope, read the conclusion. There are other factors not just backwards compatibility (which isn't even a blocker).
    - pjmlp 3y ago
      > not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening. Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. > Nope, read the conclusion. There are other factors not just backwards compatibility. Again, I wrote the Github issues regarding green threads on my comment, so I don't know, maybe I actually already read them?
      - ko27 3y ago
        > Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. The analyzers are part of the build, they work everywhere (command line, VS code). Either way, I am glad we finally agree that async await "works fine" for modern .NET. > so I don't know, maybe I actually already read them? I did, I even responded to your links with the official conclusion from the NET team on those issues. Now maybe your turn to read?
neonsunset 3y ago
You keep referencing these articles on async I think it is best that you stop. Some of the advice has been known to cause controversy, nor is necessary to think about in standard line of buisness code.
- lloydatkinson 3y ago
  100%
- pjmlp 3y ago
  I am not afraid of controversy.
0xDEF 3y ago
There are reasons Go/Erlang-like lightweight userland threads can be useful even if .Net already has a good async story.
yyyk 3y ago
The Java implementation required modifying the IO routines, and this is greatly helped by Java interop being far from easy. .NET was always more friendly to interop, lots of projects would be affected. Fixing this would either be a serious break in the ecosystem, or you'd have a new capacity with way too many asterisks to be useful. The .NET world already spent the budget for big migrations with .NET Framework -> Core (just like Java did with Java 8->9, or Python with 2->3) - as much as we might like green threads, they aren't useful enough (compared to async/await) to justify another break.

deleted 3y ago

[deleted]