к чему это синтетическое ограничение на количество потоков?переключение контекстов простаивающих потоков - это тоже не бесплатаня операция, при том абсолютно бесполезная. Чем меньше потоков выполняют один и тот же объем работ - тем выше общая производительность.
мой начальник мне говорит, что в таком случае при асинхронном режиме у нас будет делаться дополнительная работа на приостановку/возобновление и приложение, написанное в синхронном режиме будет работать быстрее (и сдохнет позже).
при превышении количества запросов (одновременно выполняемых) над количеством потоков в пуле сервер просто упадёт (в обоих режимах).
В синхронном режиме поток простаивает (он не жрёт ресурсы на вычисление, он ничего не делает).
В асинхронном режиме система создает новый поток, в него записывается весь контекст первого потока. После этого первый поток возвращается в пул и может обрабатывать другие веб запросы.
ToListAsync() из EF, что как раз связано с асинхронным вводом-выводам из БД. Здесь поток не будет выделяться сразу, а будет поставлен коллбек на системное прерывание события окончания чтения, а текущий обрабатывающий поток вернется в пул и будет ждать следующего клиента. Когда же данные появятся и их можно будет отдать клиенту - только тогда будет взят свободный тред из пула.Если в обработчике будут долгие операции, то, добавив сюда асинхронность, ОС выделит еще один поток, который будет обрабатывать этот EventLoop?
Что за риск исчерпать пул потоков? Если мы выставим значение в максимальное, то количество потоков в пуле потоков станет равно количеству системных потоков?
Про "сигналить" тоже не очень понятно.
ASYNC_NETWORK_IO. И асинхронные системные вызовы. Суть в том, что вместо цикла ожидания (синхронного) мы (то есть функция фреймворка) может попросить системное API поставить выполняться некоторую задачу с IO, а по ее окончании позвать коллбэк (который будет continuation'ом кода после await).в пуле потоков для веба содержатся системные потоки ОС?
И вот этим async/await мы просто освобождаем поток из пула, но создаем системный поток.
Получается, что нагрузка на сервер может быть увеличина, но система в целом будет загруженнее?
float - это крайне отвратительно (от чего тут у всех волосы зашевелились на руках), так делать нельзя ни в коем случае. Если вы не имеете возможности исправить биллинг, то decimal с вашей стороны поможет лишь снизить потери точности при операциях на вашей же стороне, глобально это вряд ли что-то исправит. Но это и не опасно.float и не явный decimal, а какой-нибудь спеицальный тип money, который с высокой долей вероятности будет правильно подстроенным decimal, "отрезающим" визуально лишние нули. Если же это не так, то все плохо. Ни разу в жизни не видел чтобы биллинги хранили значения баланса в таком виде, с нулями в конце. Понятно, что с точки зрения математики они ничего не решают, но вот как то не так это все.
В кордове можно использовать только то api, которое даёт кордова. Когда вы пишете на c#, у вас больше возможностей.