waitForDone

[Racheengel]

Ну, архитектуры тут нету, это чисто вопрос дизайна приложения.
Да, "плохая задача", инфа 99%
Поскольку это "главный" поток, подвешивать его в цикле - это моветон.
Задайте себе вопрос: а почему, собственно, он должен ждать?
Что происходит в момент ожидания?
Что видит юзер в этот момент? Прогресс бар или спиннер? В этом случае надо бы события обрабатывать.
Если же так прямо надо подвеситься, то проще всего решается поллингом воркера. Типичное не модное, но рабочее решение "без зауми".

[Igors]

Если же так прямо надо подвеситься, то проще всего решается поллингом воркера. Типичное не модное, но рабочее решение "без зауми".

"А я шо делаю?" (как говорят в моем регионе). while m_TaskCount и есть поллинг. Но все-таки sleep - это моветон. Где все эти прелести std:: которые якобы "тупо лучше" ? Макс, где Ваш "вариант с футурами"?

Кстати, "контроль кода" в Вашей компании пропустит sleep в цикле ?

Поскольку это "главный" поток, подвешивать его в цикле - это моветон.
Задайте себе вопрос: а почему, собственно, он должен ждать?
Что происходит в момент ожидания?
Что видит юзер в этот момент? Прогресс бар или спиннер? В этом случае надо бы события обрабатывать.

Ну это рекомендации что даются другим, сам дающий следовать им не будет Ну вот хотя бы отмена фоновой операции. Да, выставил флажок abort для воркера, но дождаться обязан, рыпаться с др событиями пока ресурс(ы) захвачен воркером - себе дороже

[RedDog]

С применением std & boost, но принцип будет понятен:

Код:

std::string fullConfig;
std::condition_variable waiter;
auto configHandler = [&waiter](const std::string& configStr, bool)
{
    fullConfig = configStr;
    waiter.notify_all();
};

boost::asio::io_context ctx;
ConfigReaderWorker worker(ctx, settings, configHandler);
std::thread configThread = std::thread(std::bind([&ctx](){ctx.run();}));

std::mutex locker;
std::unique_lock lock(locker);
waiter.wait_for(lock, []{return !fullConfig.empty();});

worker.stop();
ctx.stop();

[m_ax]

Синхронка не есть "плохо", она менее гибка, но есть масса ситуаций когда нельзя связываться с др событиями пока данная  (крытыческая) часть кода не завершена. Поэтому иногда ожидание неизбежно/необходимо. А сколько рабочих ниток (одна или N) - чисто специфика задачи.

Да, согласен, в некоторых специфичных задачах это может иметь место. Кстати, недавно же обсуждали подобную проблему: http://www.prog.org.ru/topic_32489_0.html.
Сошлись на том, что thread_pool оптимальное решение) + wrapper_pool)

[Racheengel]

Ну это рекомендации что даются другим, сам дающий следовать им не будет Ну вот хотя бы отмена фоновой операции. Да, выставил флажок abort для воркера, но дождаться обязан, рыпаться с др событиями пока ресурс(ы) захвачен воркером - себе дороже

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

[Racheengel]

Кстати, "контроль кода" в Вашей компании пропустит sleep в цикле ?

А что не так со слипом в цикле? Слип останавливает поток на некоторое время, ресурсы проца не жрутся.
Не вижу, почему это плохо

[RedDog]

А что не так со слипом в цикле? Слип останавливает поток на некоторое время, ресурсы проца не жрутся.
Не вижу, почему это плохо

Потому что поток стоит, а мог бы работать. Да и проц нечего экономить, пусть трудится.

[Racheengel]

Потому что поток стоит, а мог бы работать. Да и проц нечего экономить, пусть трудится.

Ну поток не грузовик, он когда не работает, дорогу не занимает)
Тем более в это время другие потоки шуруют во всю, если надо.

[RedDog]

Потому что поток стоит, а мог бы работать. Да и проц нечего экономить, пусть трудится.

Ну поток не грузовик, он когда не работает, дорогу не занимает)
Тем более в это время другие потоки шуруют во всю, если надо.

ОС контексты потоков все равно переключает, ей не важно спит он или нет.

[Igors]

...в некоторых специфичных задачах это может иметь место.

Опять интересно наблюдать разницу между собственными решениями и раздаваемыми рекомендациями   Помнится сами Вы ждали на мешке футур и ни о какой "асинхронке" и не помышляли.

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

Да, в моей практике этот вариант тоже самый популярный. Но разве это "честная" асинхронка? Нет, события выполняются лишь для модального окна (индикатор прогресса). Это модальная задача, а вовсе не фоновая. И это нормально, обычно др выхода просто нет. В фоне хорошо файл качать который самому не нужен (во всяком случае пока). А если обновляются активные, рабочие данные, отображаемые в UI - какой там нафиг "фон", все сразу рухнет

Кстати есои мы уж так идейны/принципиальны - то давайте заодно рассмотрим и асинхронный вариант, для него ведь тоже решений не видно (пока)

[RedDog]

Кстати есои мы уж так идейны/принципиальны - то давайте заодно рассмотрим и асинхронный вариант, для него ведь тоже решений не видно (пока)

Код:

void MainThreadWorker::onFinishShadowThread()
{
    emit workShadowThread(/* work params */)
}

[Igors]

А что не так со слипом в цикле? Слип останавливает поток на некоторое время, ресурсы проца не жрутся.
Не вижу, почему это плохо

Да, но так мы расписываемся типа "я маленький, сделать нормально не могу, вот сделал кое-как, не бейте". Но мы же не такие, правда?  

Если "чисто объективно" то уязвимое место - сколько ms? Очевидно что если потребуется "выжвть все"  то sleep не годится. Словом, неполноценное и малодушное рещение

[Igors]

С применением std & boost, но принцип будет понятен:

Вот я хочу работать так

Типовое использование

Код

C++ (Qt)
// main thread
for (...) {
  ...
  if (..)
   emit SignalDoSomething(options);  // QThreadPool::addTask(options)
  ..
}
waitForDone();

Накидал задач и жду пока все сварится

Лично мне это кажется разумным и удобным. Наделал сигналов, связал их с воркером, и просто посылаю "по ходу дела", знать не знаю ни о каких очередях, синхронизации и.т.п. Параметры задачи передаю прямо в аргументах сигнала, остальное сделает Qt.

И тут ..

Код:

std::string fullConfig;
std::condition_variable waiter;
auto configHandler = [&waiter](const std::string& configStr, bool)

на меня выливают целое ведро .. "новых технологий" И что, нужно срочно бежать все это учить? (включая дуст). То что я юзал уже не годится, устарело ("Qt только для UI"). Или как? 

Ну ладно, попробуем разобраться. Опять та же непонятка: как Вы собираетесь "подкидывать задачи по ходу дела"? Я просто сигналами, а Вы? Какой-то fullConfig, откуда его брать - хз.

Вообще, насколько это "адекввтно"? Нужны ли такие средства для решения задачи что выглядит весьма скромно? (waitForDone)

[RedDog]

Ну ладно, попробуем разобраться. Опять та же непонятка: как Вы собираетесь "подкидывать задачи по ходу дела"? Я просто сигналами, а Вы? Какой-то fullConfig, откуда его брать - хз.

Вообще, насколько это "адекввтно"? Нужны ли такие средства для решения задачи что выглядит весьма скромно? (waitForDone)

Я просто скопипастил кусок своего кода и рабочего проекта. Буст там исключительно для асинхронности (от Qt отказываемся).
Смысл в том, чтобы запустить параллельную задачу, встать на wait_condition и ждать пока в лямбде этот wait_condition не занатифает кто либо из параллельного потока.
Замените бустовый контекст на QThread а лямбду на слот, и получится то же самое.

upd:
нашел еще один проект, с похожей асинхронкой, почистил от всего лишнего, может натолкнет на мысли

[Igors]

Смысл в том, чтобы запустить параллельную задачу, встать на wait_condition и ждать пока в лямбде этот wait_condition не занатифает кто либо из параллельного потока.

Это понял, но тогда надо засисять доступ к fullConfig (по сути очередь), а делать это обычно неудобно, напр очередь пуста, но последняя задача еще тикает.

Конечно охаять чужой код - много ума не надо, но впечатление что с "современным С++" забот заметно больше - и очередь (аналог), и примитив синхронизации - все то чего хотелось избежать

Да, а "послать чистый лист бумаги" - так никто и не допер? Не может быть, наверное это просто "слишком очевидно"