Можно и так, но:
1) Поток может завершиться штатно и до завершения процесса, и тогда наши пританцовки в конце процесса для него не нужны. Надо будет исключать его из списка - еще один макрос, но уже в каждой реализации потока.
2) Очень жесткое требование, чтобы в большой программе всякое создание потоков проходило только через определенный макрос. А если мы будем это ловить в уже предоставленной системой функции DllMain, такое требование снимается.

Кроме того, с использованием DLL экзешник лаконичнее


От писателя экзешника требуется только не забыть включить одну строчку [***]. Других ошибок ему не дадут сделать компилятор и линкер.

С другой стороны, писатели потоков вообще не будут должны что-то делать. Но, когда они осознают, что могут много чего потерять при завершении процесса, и ужаснутся, им скажут - положись на ThreadMngr, и ты в 2 шагах от успеха :):
1) Поддержи у себя обработку 1 идентификационного сообщения. Дело не хитрое. Пришлют тебе ивент, а ты его и выстави. Вот тут можно и макрос предусмотреть.
2) А еще поддержи WM_QUIT. Завершайся по нему штатно. Это уж совсем просто будет, обычным образом написанный цикл обработки сообщений всегда завершится по WM_QUIT.

это да

Привет, всех с праздниками! :)

Видимо собака была зарыта в том, что без стакана с этими трэдами не разберешься, а вот теперя вроде стало яснее :). Есть наверное разные варианты, но можно вот что сделать. Почти то, что предложил saint с использованием DllMain, только которое под нашим собственным контролем (т.к. увы DllMain вызывается когда уже потоки прерваны, и причем DLL_THREAD_DETACH вообще не вызывается если завершение нештатное). И одновременно это почти то, что говорил White Owl, но только не придется выстраивать DLL в непростые последовательности зависящих друг от друга.
Вобщем, делается DLL (у меня она ThreadMngr), из которой торчит наружу такой API


Те потоки в разных DLL нашего большого проекта, которые хотят добиться того, чтобы непременно завершаться штатно, должны подлинковать эту специализированную DLL-синхронизатор. Когда они начинают свою работу, они регистрируются с помощью ThreadMngr_RegisterThread(..., TRUE). Тут заодно передаем dwThreadId, который иначе, по одному только hThread из другого потока достать затруднительно. При штатном завершении поток вызывает ThreadMngr_RegisterThread(..., FALSE). Или можно на две отдельных функции разбить, не важно.
Ну а экзешник таки перед финальным ретурном вызывает ThreadMngr_WaitThreads(). И в нем что-то типа


White Owl
Бармолей
Библиотеки, использующие мою, о корректном завершении заботиться не должны - все перекладываем на экзешник. Для этого замутить отдельную DLL.

Вот на такой подход я точно буду ругаться :)
Одно дело знать что используемая библиотека требует явного старта и финиша (те самые DLL_Init() и DLL_Shutdown()) и совсем другое дело подключать какую-то еще dll причем надо будет следить чтобы она стартовала ДО рабочей dll и финишировала ПОСЛЕ нее. Получаем в итоге ту же самую проблему от которой пытались уйти только в еще более неудобном для решения виде.

Может я выразился в прошлый раз не так. В итоге получается, что о всех этих делах заботятся 2 стороны:
1) сам тот поток, который не хочет быть прерван "на полуслове"
2) экзешник, который "всему голова" :)
А разные "третьи" возможные участники, ну то есть еще другие DLL, которые используют ту, которая генерит потоки, вот они уже не заботятся о вопросах корректного завершения тех потоков.

Вроде так нормальненько :)).

White Owl БармолейМожет я выразился в прошлый раз не так. В итоге получается, что о всех этих делах заботятся 2 стороны:
....
Вроде так нормальненько :)).
Да нет, все так выразился. Просто вот наличие "специализированной DLL-синхронизатора" мне и не нравится. Совсем.
А что плохого?

А, понял. У тебя, выходит дело, уже есть такая система правил в проекте:
1) У всех dll должен быть инит и шатдаун
2) Если в одной dll используешь другую длл, то должен ей форвардить эти вызовы
3) Делаешь что-то типа подсчета ссылок, или еще как, но так чтобы 2 раза не заинититься и не зашатдауниться

При таком раскладе да, уже есть место, где "всяко завершать", ну и тогда само собой просится сунуть ожидание потоков тоже в ту же шатдаун. Тут наверное нужны еще некие базовые классики, чтобы не повторять код... Ну а так как у меня нет такой глобальной системы, а вводить ее на данном этапе по ряду причин довольно проблемно, то пока что более локальным решением может быть сервис в виде отдельной dll, узко направленный конкретно на решение задач с потоками, то есть "синхронизатор" этот. На exe при этом ложится только задача обеспечения финального вызова
что не такая уж большая заморочка. А вот уже рабочие длл, порождающие свои потоки, при условии что они хотят завершаться штатно, должны будут приложить доп усилия в виде регистрирации.

По-моему тут во многом дело вкуса и проектной ситуации - на какой манер делать.

White Owl БармолейА, понял. У тебя, выходит дело, уже есть такая система правил в проекте:
1) У всех dll должен быть инит и шатдаун
2) Если в одной dll используешь другую длл, то должен ей форвардить эти вызовы
3) Делаешь что-то типа подсчета ссылок, или еще как, но так чтобы 2 раза не заинититься и не зашатдауниться
Нет, не правильно :)
1) Процедуры MyDLL_Init()/MyDLL_Shutdown() есть только у некоторых dll. Которым есть что инитить и шатдаунить :) Соотвественно в документации на эти dll явно сказано о необходимости этой пары (или только одной из) функций.
2) Никуда я ничего не форваржу. Если DllA использует DllB, а я из основной программы не обращаюсь к DllB, то соответсвенно мне совершенно до лампочки как DllA работает с DllB. У меня в программе есть DllA_Init() и DllA_Shutdown(). Все. Что там происходит внутри DllA меня не волнует.
3) Ну и соотвественно никаких подсчетов ссылок и ни о каких двойных ссылках я не забочусь. Если Dll не должна инитится дважды и/или должна обслуживать несколько программ одновременно, то она (dll) сама об этом заботится. Например создает мутекс во время своего Dll_Init и разбирается надо ли его удалять при Dll_Shutodown. Из основной программы я ничего не делаю совсем.

1) Так у тя еще и документация есть??!! :)) Ну ты это, вообще счастливчик, если она настолько приближена к реализации и при этом еще и в актуальном состоянии поддерживается.
2) Когда ты говоришь, что не форвардишь это имеется ввиду что экзехе пофиг что дальше сделает DLLA? Ну это круто, но ведь реально то все-таки будут возникать ситуации форварда. Вот например, есть у тебя цепочка использования EXE -> DllA -> DllB -> ... -> DllY -> DllZ. И вдруг DllZ, возьми себе да и реализуй новый функционал, где появляются потоки. Так автор DllZ должен сообщить своему другу, пишущему DllY: "ты теперь зови мне инит и шатдаун!", а тот автору DllX и т.д. вплоть до писателя экзешника. И вот, дописывая эту шатдаун, они только и должны будут, что вызвать шатдаун того, кого они используют. Про это я и говорил, что это форвардинг (он остается таковым даже если вызывающий модуль не вдается в то что происходит).
3) Когда ты говоришь "я не забочусь о подсчете ссылок" ты, вероятно имеешь ввиду вызывающую сторону, например экзешник. Ну а вызываемая сторона если только ее шатдаун и инит не сводятся к соответствующим форвардам, никуда не денется от того, чтобы как то позаботиться о возможности повторных вызовов. Поэтому, то что ты не делаешь контроль повторных вызовов означает скорее всего, что его делают другие.

White Owl
БармолейПо-моему тут во многом дело вкуса и проектной ситуации - на какой манер делать.
Это конечно да.... Просто подход который я описываю работает уже много-много лет, в очень-очень многих freeware/shareware и разных других ~ware рантайм-библиотеках :)
Клево :) Да, очень часто, когда кто-нибудь делал что-нибудь много-много лет, то он уже обычно и дальше продолжает в том же стиле, особенно если это приводит к результату, и в этом нет ничего плохого, если все это вполне работает. :)

Спасибо