Open Aaronontheweb opened 4 months ago
When using async await, the naughty compiler generates state machines, this cause several blocking issues:
Using Task.Result
fixes all these issues.
Unknown compiler bugs might generate incorrect state machines.
Should I flag this as a security issue then too? Seems scary to me
Tasks are evil in general, they result is threading issues and will need to be allocated to local and global queues which the threads in the ThreadPool need to steal from each other creating extra work for the Thread, the CLR and CPU. Synchronous code is always the better option, simpler to reason about, no allocation and lighter on the pool. Creating new Threads is the way to go.
ThreadPool need to steal from each other creating extra work for the ThreadPool
Wow, so await
is THEFT?!?!
ThreadPool need to steal from each other creating extra work for the ThreadPool
Wow, so
await
is THEFT?!?!
We would need to involve the legal dep to be sure, but for now legal, security, performance and geopolitical risks associated with the feature clearly warrant it to be banned.
One 100 percent. This is one of the best kept secrets within Microsoft, nobody can talk about it cause they are all under NDA. Now you know where the money to keep Azure running is coming from.
I'm ready to die on this heap.
Revolution
@jmderuty Sure, some of us are ready to die on that heap, but are you ready to die on that stack?
@jmderuty Sure, some of us are ready to die on that heap, but are you ready to die on that stack?
Actually, async await destroys stacks. That's one of its crimes.
Why? It's too difficult to reason about what's going on with all of these crazy
Task<T>
everywhere. We should just useTask.Result
as that's more management-friendly.