Как AsyncController избегает использования рабочего потока ASP.NET? - PullRequest
5 голосов
/ 02 августа 2011

Как именно AsyncController избегает использования рабочего потока ASP.NET?Если я использую шаблон на основе событий (псевдокод):

[AsyncTimeout(60000)]
public void WaitForWakeUp() 
{
    AsyncManager.OutstandingOperations.Increase();
    EventRaisedElsewhere += 
    state => 
    {
        AsyncManager.OutstandingOperations.Decrease();
        return Content("Woke up because of " + state);
    };
}

... тогда согласно Clay Lenharts он не использует рабочий поток ASP.NET.Как это возможно?

Я немного заглянул в исходный код AsyncController, но ничего не понял, за исключением того, что он использует IAsyncResult много и в некоторых местах QueueUserWorkItem.

Но как BeginInvoke и QueueUserWorkItem не могут использовать рабочий поток ASP.NET?Конечно, оба из них используют поток пула потоков, и, конечно, в рабочем процессе ASP.NET есть только один пул потоков?

Согласно MSDN,

Веб-сервер получаетпоток из пула потоков (рабочий поток) и планирует его для обработки входящего запроса.Этот рабочий поток инициирует асинхронную операцию .

Рабочий поток возвращается в пул потоков для обслуживания другого веб-запроса.

Когда асинхронная операция завершена, он уведомляет об этомASP.NET.

Но для чего-то нетривиального это звучит так: инициирует асинхронную операцию по-прежнему требует выполнения потока.Только в очень простых случаях (например, при использовании BCL для загрузки веб-контента) он будет полностью размотан и / или полностью привязан к IOCP, верно?

Я спрашиваю частично, потому что вижу все эти серверы чата, реализованные с использованием AsyncController и если все, что они делают - это «ждут новых сообщений», я не понимаю, как это можно сделать в потоке, не являющемся пулом.

1 Ответ

0 голосов
/ 03 августа 2011

Вы вроде как правы.Он использует поток asp.net для инициирования асинхронного вызова, но этот поток завершается и возвращается в пул.Затем асинхронный процесс выполняется в другом потоке из пула рабочих потоков, прежде чем уведомить asp.net, что ему нужен поток для обработки результата.

он более эффективен, поскольку пул потоков asp.net ограничивает входящие соединения, поэтомуосвобождение их как можно скорее позволяет вам быстрее справляться с другими входящими соединениями.

По крайней мере, так я это вижу.

Редактировать Не думаю, что этосовершенно верно.Существует только один фоновый пул потоков, как определено в платформе, но вы можете создать столько других потоков, сколько захотите, и создать свой собственный пул потоков, отличный от фонового пула потоков.

Я полагаю, что этоздесь происходитСуществует небольшое количество рабочих потоков, обрабатывающих запросы.Эти рабочие потоки порождают потоки в фоновом пуле для обработки асинхронных запросов.

Simon

...