Здравствуйте, Maxim S. Shatskih, Вы писали:

C>>Искусственные лимиты полезны — мы можем дать гарантию, что запрос обработается максимум за N секунд, если он таки был принят на исполнение. Если же у нас нет лимита — возможна ситуация, когда очередь будет расти неограничено.
MSS>Если у вас просчитаны времена худшего случая для абсолютно всех стадий исполнения, в т.ч., например, время дергания головкой в диске вместе с ее возможной тепловой рекалибрацией, и с учетом других процессов, которые тоже оной головкой дергают (Content Index, например, или да мало ли что там еще в ОС живет)- то да.
MSS>Но это ну крайне сложно, а в не-риалтаймовой ОС — невозможно, хотя бы потому, что вашу нить может прервать еще что-то (UI например, а то и вовсе скрин-сейвер) — и прервать зачастую на значительное время.
Я не говорю про 100%-ную точность до микросекунд с гарантией от попадания астероида. Я говорю про практические гарантии. Например, сетевая карта гарантировано передаст пакет в "ближайшее время", если он все-таки был поставлен в ее очередь — мы можем на это рассчитывать.

Кстати, еще один способ обрабатывать переполнение очереди — просто выбрасывать переполняющие пакеты.

C>>За такие хаки я бы лично ногами бил разработчиков. Код должен работать на максимум пропускной способности.
MSS>Постойте, а зачем тогда лимиты?
Лимиты должны находится в "серверном" коде. Клиент должен либо блокироваться, либо получать EWOULDBLOCK'ом по зубам. Заниматься планированием нагрузки он не должен.

C>>Ограничивать ее — дело операционной системы (планировщиков IO,
MSS>В какой это ОС у нас есть планировщик дискового IO? в виндах до Висты не было никакого, был только elevator seek и использование SCSI tagged queue, да и в Висте какой-то убогий.
Ээээ... Linux (http://www.linuxjournal.com/article/6931 http://kerneltrap.org/node/3851), Solaris, AIX? ionice в Линуксе так уже года четыре есть — использовал пару раз.

C>>процессора, сети — они лучше свою работу знают).
MSS>А вы никогда не встречались с требованием "ограничить сетевой трафик, создаваемый системой"? или "ограничить disk IO трафик, создаваемый системой"?
Не сталкивался. Если бы столкнулся — настроил бы правила файрвола. Disk io-траффик — это сложнее, особенно в Windows.

MSS>Совершенно запросто под виндами можно написать приложеньице, которое забьет дисковый IO так, что подвиснет shell UI на первом же page fault в shell32.dll или explorer.exe. Юзеры этого не любят.
И что дальше? Всем ставить Sleep(100) после каждого вызова ReadFile?

MSS>Вот для реализации этих требований и делают ReadFile+Sleep, что есть полная эмуляция более медленного диска (особенно если нить высокоприоритетна).
Не делает. Это идиотский хак, который маскирует убогость планировщика. Так как банальные 10 операций чтения одного блока будут выполнятся медленнее, чем если бы читалось с дискеты.

C>>Такие sleep-хаки могут привести к паталогическим случаям, если две программы будут просыпаться в одно и то же время — они будут обе считать, что процессор загружен на 100%.
MSS>С загрузкой _процессора_ тут надо быть осторожнее, это да, для нее лучше GetThreadTimes использовать — сколько времени бежала именно данная нить на процессоре.
Может быть не процессор, а сеть, например (ее проще загрузить). Умные планировщики знают состояние ВСЕЙ системы и спокойно избегают таких случаев, а вот самопальный хак — самоспалится.