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

В низкоуровневых протоколах, которые либо заявлены как ненадежные (UDP), либо имеют ретрансмит (TCP) — это и делается.

Но на уровне приложения? выдать юзеру "сервер перегружен, попробуйте позже" — это омерзительно. Уж лучше пусть тормозит незнамо как из-за перегрузки, например, канала. Лучше потому, что время выполнения юзерской операции в первом случае уж точно не будет меньше, плюс от юзера требуется лишний раз нажать мышой.

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

Не всегда речь об архитектурах клиент-сервер. Часто речь о настольной апликации, которая на 100% грузит disk IO.

Что до клиент-сервер — то тут да, я не понимаю, зачем лимиты в клиенте.

MSS>>В какой это ОС у нас есть планировщик дискового IO? в виндах до Висты не было никакого, был только elevator seek и использование SCSI tagged queue, да и в Висте какой-то убогий.
C>Ээээ... Linux (http://www.linuxjournal.com/article/6931

И чего? примерно то же, что в виндах, разница в мелочи. Самое главное — в статье по ссылке нет понятия "IO приоритет процесса" и планирования дисковых реквестов в зависимости от того, кто их издал. Этого нет и в виндах.

C>http://kerneltrap.org/node/3851

И тут такая же петрушка, кроме того, что модули шедулеров сменные, и еще и на ходу.

), Solaris, AIX? ionice в Линуксе так уже года четыре есть — использовал пару раз.

А сколько народу у нас пишут под винды? а насколько портабелен такой код?

C>Не сталкивался. Если бы столкнулся — настроил бы правила файрвола.

То есть предполагается, что для работы вашей софтины юзер должен иметь файрволл? хороший подход для ляпов на коленке, плохой — для продукта.

C>Disk io-траффик — это сложнее, особенно в Windows.

Что сложного? добавь Sleep, и все. Альтернатив в винде нет — там lazy writer не помнит, какой процесс испачкал страницы кэша, таким образом, задать по-процессный приоритет _на слив кэша_ невозможно в принципе.

C>И что дальше? Всем ставить Sleep(100) после каждого вызова ReadFile?

Не всем, и не 100. Надо замерять, сколько времени выполнялись дисковые операции, каков незатротленный disk IO bandwidth, и на основании этого рассчитывать длительность каждого Sleep персонально. Иногда она может оказаться равной нулю, в коем случае вообще не надо звать Sleep.

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

Вот жизнь у нас такая идиотская. Ну нет в винде управляемого планировщика дисков и понятия "IO приоритет процесса", и часть причин к тому — архитектурные (Cc не помнит, какой процесс какие страницы испачкал). Живем мы так.

И приходится не заниматься глупыми мечтами о прекрасном мосте, а решать задачу простейшим и работающим образом на реальной архитектуре в реальном продукте.

Если параметр Sleep правильно рассчитывается — то можно системе извне задать значение "процент disk IO bandwidth, который позволено откушать". И одним лишь Sleep вместе со взятием временных меток — задача решается с достаточной степенью точности.

C>Может быть не процессор, а сеть, например (ее проще загрузить).

Нет, с процессором у нас чуть иначе все. С процессором сложность в снятии адекватных статов его загрузки данной нитью. Снятие меток времени до и после CPU-bound кода — действительно идиотизм, ты прав. Тут нужен только и исключительно GetThreadTimes.

C>Умные планировщики знают состояние ВСЕЙ системы и спокойно избегают таких случаев, а вот самопальный хак — самоспалится.

Что вы предлагаете? для ограничения сетевого трафика, создаваемого софтом, обращаться к psched? какова цена реализации такого дела?

Как ограничить дисковый трафик конкретного процесса на виндах?

То, что вы назвали идиотским хаком, есть нормальная реальное инженерное решение проблемы на конкретной массовой ОС, а не маниловские мечтания о том, какой должна быть правильная ОС.

При правильном кодировании ничего там не самоспалится, или самоспалится ненамного, не навсегда и в предсказуемую сторону.