Альтернатива шаблона разработки сопрограммам

Все главные браузеры поддерживают HttpOnly.

  • Microsoft IE 5.0 +
  • Mozilla Firefox 1.0 +
  • Google Chrome
  • Apple Safari
  • Opera 8.0 +
12
задан jameszhao00 24 August 2009 в 04:42
поделиться

7 ответов

Вы можете моделировать совместную микропоточность с помощью IEnumerable. К сожалению, это не будет работать с блокирующими API-интерфейсами, поэтому вам нужно найти API-интерфейсы, которые можно опрашивать или у которых есть обратные вызовы, которые можно использовать для сигнализации.

Рассмотрим метод

IEnumerable Thread ()
{
    //do some stuff
    Foo ();

    //co-operatively yield
    yield null;

    //do some more stuff
    Bar ();

    //sleep 2 seconds
    yield new TimeSpan (2000);
}

Компилятор C # развернет это в состояние машина, но внешний вид похож на кооперативную микронить.

Схема довольно проста. Вы реализуете «планировщик» который хранит список всех активных IEnumerators. По мере того, как он проходит по списку, он «запускает» каждый с помощью MoveNext (). Если значение MoveNext ложно, поток завершен, и планировщик удаляет его из списка. Если это правда, то планировщик обращается к свойству Current, чтобы определить текущее состояние потока. Если это TimeSpan, поток желает засыпать, и планировщик переместил его в некоторую очередь, которая может быть сброшена обратно в основной список по истечении временных интервалов сна.

Вы можете использовать другие возвращаемые объекты для реализации других механизмов сигнализации. Например, определите какой-нибудь WaitHandle. Если поток возвращает одно из них, его можно переместить в очередь ожидания, пока дескриптор не получит сигнал. Или вы можете поддержать WaitAll, предоставив массив дескрипторов ожидания. Вы даже можете реализовать приоритеты.

Я выполнил простую реализацию этого планировщика примерно за 150 мест, но я еще не дошел до написания кода в блоге. Это было для нашей оболочки PhyreSharp PhyreEngine (которая не будет общедоступной), где она, кажется, неплохо работает для управления парой сотен символов в одной из наших демонстраций. Мы позаимствовали эту концепцию у движка Unity3D - у них есть несколько онлайн-документов, которые объясняют это с точки зрения пользователя.

9
ответ дан 2 December 2019 в 06:09
поделиться

Разве это не обычное использование многопоточной обработки?

Взгляните на такие шаблоны, как Reactor здесь

1
ответ дан 2 December 2019 в 06:09
поделиться

Написание его для использования Асинхронного ввода-вывода может быть достаточно.

Это может привести к легкому и трудному отладке кода без сильной структуры в дизайне.

1
ответ дан 2 December 2019 в 06:09
поделиться

Это непростой вопрос, на который можно ответить простым числом запросов в минуту.

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

Итак, это зависит от вашего сервера и того, что он может обрабатывать. Это также зависит от вашей точки зрения. Например, старый 386 может обрабатывать жалкие 50 запросов в минуту. Я бы назвал это легкой нагрузкой. Но сервер с высокими техническими характеристиками может обрабатывать 60000 запросов в минуту. Это всего лишь предположение. Понятия не имею, сможет ли Apache это сделать. Наше телекоммуникационное программное обеспечение, безусловно, может.

Я думаю, что лучше всего ответить на этот вопрос с точки зрения сервера. Я бы сказал, что очень большая нагрузка - это когда вы находитесь в пределах 10% от того, что ваш сервер способен обрабатывать, в течение нескольких или десятков минут. Большая нагрузка в пределах 15%.

Это позволит вам получать непрерывный набор из N задач из вашей очереди. Вы можете манипулировать N, чтобы повлиять на характеристики производительности и найти то, что лучше всего в ваших конкретных обстоятельствах.

Поскольку вы в конечном итоге ограничены аппаратными операциями (дисковый ввод-вывод и сетевой ввод-вывод, ЦП), я полагаю, что чем меньше, тем лучше. Две задачи пула потоков, работающие с дисковым вводом-выводом, скорее всего, не будут выполняться быстрее, чем одна.

Вы также можете реализовать гибкость в размере и содержании активного списка задач, ограничив его заданным числом задач определенного типа . Например, если вы работаете на машине с 4 ядрами, вы можете обнаружить, что наиболее производительная конфигурация - это четыре задачи с привязкой к ЦП, выполняющиеся одновременно, одна задача с привязкой к диску и сетевая задача.

Если у вас уже есть одна задача. классифицируется как задача ввода-вывода диска,

5
ответ дан 2 December 2019 в 06:09
поделиться

Дополнительная информация о шаблоне «Реактивный» (как упомянуто другим автором) в отношении реализации в .NET; иначе «Linq to Events»

http://themechanicalbride.blogspot.com/2009/07/introduction-rx-linq-to-events.html

-Oisin

0
ответ дан 2 December 2019 в 06:09
поделиться

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

2
ответ дан 2 December 2019 в 06:09
поделиться
Другие вопросы по тегам:

Похожие вопросы: