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

_>>Ну вот простейшая классическая задача: скопировать файл (читаем его в буфер в памяти и параллельно записываем на диск в новое место). Эта задача собственно вот только в диск и упирается. И ты реально считаешь, что для её реализации будут эффективнее сопрограммы с асинхронным вводом-выводом? )))
MA> Она не простейшая. В FAR был почивший? плагин делающий это хотя бы эффективно. Нужно один/два больших буфера (очень больших, типа 16Мб+) — в него асинхронно читаешь максимально большими блоками (буфер должен уметь в много файлов) — ну параллельно пишешь. Тебе не нужно 2 потока для чтнения/записи и их данных — ты можешь просто дирижировать из одного потока, тем самым не израсходовав ресурсы (стэк, прочие ресурсы на поток). Стратегии копирования с одним HDD — одни, а с несколькими — другие.

Если мы говорим о нескольких потоках (а не о тысячах), то это нельзя считать тратой ресурсов. ) А приносит это очень существенную прибыль: упрощение архитектуры + увеличение надёжности (GUI точно не станет подвисать, как это возможно в случае async при классическом подходе).

_>>Или же просто запустить эту операцию в отдельном потоке. ))) Что будет намного проще и эффективнее.
MA> Вернемся к тому, что нужен будет "арбитр" связующий задание и UI и трэкающий события. Вспоминаем классику MFC и радуемся беспорядочным посылкам непонятно чего. Ничего проще тут нет.

Не очень понял причём тут MFC. Но если мы говорим о UI потоке, то он и так априори сидит на цикле сообщений, так что добавление ему обработки ещё одного, нового, не даст никаких усложнений. Ну а исполняющему задачу потоку не надо вообще ничего "трекать", т.к. он будет работать с синхронным API.

MA>Ну про преимущества пула vs на каждый чих создавать потоки можно долго спорить (я бы лично создавал чаще, чем держал 10 бесполезных потоков). Но сейчас то точно все тюнится. В чем проблема. Более того таскм есть LongRunning. Предпочитаешь Thread vs TPL — твое право. И то и то имеет место быть в практике.

Пул потоков (обычно с числом потоков, равным числу логических ядер) полезен в основном для тех задач, которые полностью загружают процессор. Это как раз случаи нагруженных сервисов (тогда в каждом таком потоке тысячи асинхронных задач крутятся) и случае различных вычислений (тут просто распараллеливают набор данных по числу ядер).

А вот для случая привнесения "пользовательской асинхронности" (т.е. когда грубо говоря задача на закачку файла не блокирует весь UI до её исполнения) как раз правильнее использовать классический запуск фонового потока.