Support async: Blocking IO leads to ThreadPool starvation and limits scalability
Description
1. I can't use `await` while holding NHibernate session otherwise eventually all TP threads will deadlock waiting for connection pool to free a connection while there are no threads to complete it.
2. I'm limited in using `await` outside of NHibernate sessions because when almost all TP threads are blocked by IO, continuations execution is limited and may be delayed significantly increasing requests latency.
3. TP threads by design should never be blocked otherwise application scalability is limited.
So "blocking IO doesn't really affect app performance" is a lie. Please reconsider your decision about supporting async.
For better "Future query" feature semantic and for support of async with "Future query", future queries will no more yield a deferred IEnumerable<T> but an IFutureEnumerable<T>. It is still an IEnumerable<T> for backward compatibility, but this may be dropped in a future version. Use IFutureEnumerable<T>.GetEnumerable() instead. It does trigger pending future queries.
Frédéric Delaporte
March 28, 2017 at 2:20 PM
(edited)
So "blocking IO doesn't really affect app performance" is a lie. Please reconsider your decision about supporting async.
I am not aware of any decision about banning async support. Instead, there are some ongoing works. See and comments.
1. I can't use `await` while holding NHibernate session otherwise eventually all TP threads will deadlock waiting for connection pool to free a connection while there are no threads to complete it.
2. I'm limited in using `await` outside of NHibernate sessions because when almost all TP threads are blocked by IO, continuations execution is limited and may be delayed significantly increasing requests latency.
3. TP threads by design should never be blocked otherwise application scalability is limited.
So "blocking IO doesn't really affect app performance" is a lie. Please reconsider your decision about supporting async.