5 ms·

I love C#, but I also don't find async and await in JS to be too bad. It's easy enough to wrap a non async library with promises so I can use it with async and

by rpeden 8y ago

I love C#, but I also don't find async and await in JS to be too bad. It's easy enough to wrap a non async library with promises so I can use it with async and await. I've sometimes done the same thing with non-async libraries in C# by wrapping them with Tasks.

dhd415 8y ago
Wrapping a sync method in a Task causes a thread to block on the sync method's completion and blocking threads is much of what async/await is intended to alleviate.
- whoisthemachine 8y ago
  I'd be inclined to believe he means wrapping an asynchronous method (with callbacks) in a Task.
manigandham 8y ago
Wrapping non-async code with a Task doesn't do anything. It's only useful if you need to pass a Task around instead, or need to move that work to a different thread. Otherwise you might as well block in the method you're already executing instead of adding more overhead.
- int_19h 8y ago
  I think they meant wrapping it so that it runs in a background thread, e.g. with Task.Run.
- rpeden 8y ago
  You're absolutely right! It doesn't make sense to do this most of the time. I wrote my original message in a rush and left out a lot of context. I usually only do this when I'm pretty sure I'll have to farm out the functionality to a separate service in the very near future. I just start with an async facade around the library, and then swap in an async wrapper around the web service when the time comes. Then I can just drop it in without needing to make any changes aside from changing the interface binding in the DI container initialization. I suppose this might violate YAGNI. But I really don't do it often at all. I only doing it when I'm following the principle of PSIGNIS (Pretty sure I'm going to need it soon). Maybe it's better to just use the library synchronously and then refactor when it's time to move the functionality to a separate service. I don't think the amount of dev time spent is hugely different either way.

by rpeden 8y ago

dhd415 8y ago

Wrapping a sync method in a Task causes a thread to block on the sync method's completion and blocking threads is much of what async/await is intended to alleviate.

whoisthemachine 8y ago
I'd be inclined to believe he means wrapping an asynchronous method (with callbacks) in a Task.

manigandham 8y ago

Wrapping non-async code with a Task doesn't do anything. It's only useful if you need to pass a Task around instead, or need to move that work to a different thread. Otherwise you might as well block in the method you're already executing instead of adding more overhead.

int_19h 8y ago
I think they meant wrapping it so that it runs in a background thread, e.g. with Task.Run.
rpeden 8y ago
You're absolutely right! It doesn't make sense to do this most of the time. I wrote my original message in a rush and left out a lot of context. I usually only do this when I'm pretty sure I'll have to farm out the functionality to a separate service in the very near future. I just start with an async facade around the library, and then swap in an async wrapper around the web service when the time comes. Then I can just drop it in without needing to make any changes aside from changing the interface binding in the DI container initialization. I suppose this might violate YAGNI. But I really don't do it often at all. I only doing it when I'm following the principle of PSIGNIS (Pretty sure I'm going to need it soon). Maybe it's better to just use the library synchronously and then refactor when it's time to move the functionality to a separate service. I don't think the amount of dev time spent is hugely different either way.