Пишу веб-спайдер. Чтобы загрузить канал и компенсировать network latency, приходится ввода-вывод выполнять параллельно. Сейчас это сделано блокирующими сокетами и многопоточностью.

Достоинство архитектуры — простота работы с синхронными вызовами.
Недостатки:
— необходимость выделения стека каждому потоку
— большую часть времени все потоки ожидают завершения ввода, т.е. простаивают

В MSDN рекомендуетcя для повышения производительности использовать вместо тысяч потоков thread pools. Но из cтатьи Platform SDK: Thread Pooling и непосредственно документации по QueueUserWorkItem() function непонятно, как работает thread pool.

Конкретно, не ясно как организована эта постановка в очередь, в чем отличие от CreateThread() function. IMHO, параметры и их назначение одинаковы, отличается только scheduling. А как конкретно планировщик работает в случае пула, какой производительности ожидать — неясно. Ведь меня не устраивает если одновременно будет установлено всего 10 соединений, а остальные ждать в очереди — производительность будет низкой.

Здравствуйте, nimnul2, Вы писали:

[]

Сходи, купи 2 номер RSDN Mag за этот год. См. здесь