4 ms·

I'm a heavy C# user, but I come from a classical background and I have yet to start using async/await stuff. My reason (and I know this is terrible and I need

by 13of40 10y ago

I'm a heavy C# user, but I come from a classical background and I have yet to start using async/await stuff. My reason (and I know this is terrible and I need to get over it) is I can't make heads or tails of it when I'm looking at the jitted code in NTSD.

maxxxxx 10y ago
I was in the same position but I would recommend you start using it. Make sure you start with a small project and really step through each line so you can predict what will run in which thread. I notice that some people use async/await but don't really understand it which can cause problems in some situations. It definitely makes life much easier. Can't wait to use it in JavaScript.
- jermaustin1 10y ago
  This, so much. My first deep dive into it I ended up in async hell. Definitely start one call at a time in a small corner of a small application. Once you understand async Task Method() vs async Task<Result> Method(), then how the async methods all chain back together, you can expand it.
  - maxxxxx 10y ago
    The funny thing is you can use async successfully without having a clue. But one day it will bite you hard.
    - naasking 10y ago
      This is really a problem for .NET itself. The pervasive availability of thread-static state is the only way async/await could really go wrong.
      - maxxxxx 10y ago
        There is more that can go wrong. For example in a desktop app a button click finishes before the async code has been executed. The code looks like it's blocking but it isn't. I have seen that a few times now.
j_s 10y ago
In addition, many ASP.NET server-side projects had a fun time making changes required to properly survive cross-thread transfer of per-request data. (This was possible in the past but rarely happened.) https://github.com/Glimpse/Glimpse/issues/632 https://github.com/Glimpse/Glimpse/issues/632
- tracker1 10y ago
  You can see similar issues with lifecycle events on load... load/render may happen in different threads as well under heavy load, I've seen a lot of race conditions with these kinds of assumptions.. also, a lot of people tend not to understand static in a web server context as well.
barrkel 10y ago
This question I answered many moons ago may be useful: http://stackoverflow.com/questions/1296683/curiosity-why-does-expression-when-compiled-run-faster-than-a-minimal-dyna http://stackoverflow.com/questions/1296683/curiosity-why-doe... Combined with this approach to debugging using `.load sos`: http://blog.barrkel.com/2006/07/not-so-lazy-garbage-collector.html http://blog.barrkel.com/2006/07/not-so-lazy-garbage-collecto... The SOS debugging extension makes following JITted code much easier. Of course if you're looking at async code, or the body of an iterator method, or a lambda body that's capturing variables, you need to understand those high-level transformations first.

by 13of40 10y ago

maxxxxx 10y ago

I was in the same position but I would recommend you start using it. Make sure you start with a small project and really step through each line so you can predict what will run in which thread. I notice that some people use async/await but don't really understand it which can cause problems in some situations. It definitely makes life much easier. Can't wait to use it in JavaScript.

jermaustin1 10y ago
This, so much. My first deep dive into it I ended up in async hell. Definitely start one call at a time in a small corner of a small application. Once you understand async Task Method() vs async Task<Result> Method(), then how the async methods all chain back together, you can expand it.
- maxxxxx 10y ago
  The funny thing is you can use async successfully without having a clue. But one day it will bite you hard.
  - naasking 10y ago
    This is really a problem for .NET itself. The pervasive availability of thread-static state is the only way async/await could really go wrong.
    - maxxxxx 10y ago
      There is more that can go wrong. For example in a desktop app a button click finishes before the async code has been executed. The code looks like it's blocking but it isn't. I have seen that a few times now.

j_s 10y ago

In addition, many ASP.NET server-side projects had a fun time making changes required to properly survive cross-thread transfer of per-request data. (This was possible in the past but rarely happened.) https://github.com/Glimpse/Glimpse/issues/632 https://github.com/Glimpse/Glimpse/issues/632

tracker1 10y ago
You can see similar issues with lifecycle events on load... load/render may happen in different threads as well under heavy load, I've seen a lot of race conditions with these kinds of assumptions.. also, a lot of people tend not to understand static in a web server context as well.

barrkel 10y ago

This question I answered many moons ago may be useful: http://stackoverflow.com/questions/1296683/curiosity-why-does-expression-when-compiled-run-faster-than-a-minimal-dyna http://stackoverflow.com/questions/1296683/curiosity-why-doe... Combined with this approach to debugging using `.load sos`: http://blog.barrkel.com/2006/07/not-so-lazy-garbage-collector.html http://blog.barrkel.com/2006/07/not-so-lazy-garbage-collecto... The SOS debugging extension makes following JITted code much easier. Of course if you're looking at async code, or the body of an iterator method, or a lambda body that's capturing variables, you need to understand those high-level transformations first.