Сообщение Re[2]: std::thread, std::condition_variable и dll от 14.06.2021 6:12
Изменено 15.06.2021 5:12 DDDX
Re[2]: std::thread, std::condition_variable и dll
Здравствуйте, ononim, Вы писали:
O>Вникать лень но что сказать имею.
O>В винде _НИЗЗЯ_ ждать завершения потока из DllMain — это вызовет дедлок по неочевидным для простого писателя кода причинам. Это означает в том числе что нельзя ждать завершения потока в деструкторе статик объектов, которые объявлены в длл (так как эти деструкторы исполняются из DllMain).
Ага.
Общее правило, которое я выработал для себя:
У DLL должны быть функции инициализации и деинициализации. Можно (лучше) с глобальным счетчиком вызовов.
При обнулении этого счетчика, DLL должна прекратить все свои фоновые потоки.
---
Можно без обойтись без этих функций.
Тогда DLL должна предоставлять объекты, которые (автоматически) рулят этим глобальным счетчиком использования DLL.
---
Частный пример — DLL сервер COM объектов.
При освобождении последнего COM-объекта, DLL должна прекращать все свои фоновые потоки. Это делается вне DllMain
---
Кстати, если я все правильно помню, у Рихтера еще в третьем издании (это ~98 год) было описана эта проблема, которую он отважно победил
O>Вникать лень но что сказать имею.
O>В винде _НИЗЗЯ_ ждать завершения потока из DllMain — это вызовет дедлок по неочевидным для простого писателя кода причинам. Это означает в том числе что нельзя ждать завершения потока в деструкторе статик объектов, которые объявлены в длл (так как эти деструкторы исполняются из DllMain).
Ага.
Общее правило, которое я выработал для себя:
У DLL должны быть функции инициализации и деинициализации. Можно (лучше) с глобальным счетчиком вызовов.
При обнулении этого счетчика, DLL должна прекратить все свои фоновые потоки.
---
Можно без обойтись без этих функций.
Тогда DLL должна предоставлять объекты, которые (автоматически) рулят этим глобальным счетчиком использования DLL.
---
Частный пример — DLL сервер COM объектов.
При освобождении последнего COM-объекта, DLL должна прекращать все свои фоновые потоки. Это делается вне DllMain
---
Кстати, если я все правильно помню, у Рихтера еще в третьем издании (это ~98 год) было описана эта проблема, которую он отважно победил
Re[2]: std::thread, std::condition_variable и dll
Здравствуйте, ononim, Вы писали:
O>Вникать лень но что сказать имею.
O>В винде _НИЗЗЯ_ ждать завершения потока из DllMain — это вызовет дедлок по неочевидным для простого писателя кода причинам. Это означает в том числе что нельзя ждать завершения потока в деструкторе статик объектов, которые объявлены в длл (так как эти деструкторы исполняются из DllMain).
Ага.
Общее правило, которое я выработал для себя:
У DLL должны быть функции инициализации и деинициализации. Можно (лучше) с глобальным счетчиком вызовов.
При обнулении этого счетчика, DLL должна прекратить все свои фоновые потоки.
---
Можно обойтись без этих функций.
Тогда DLL должна предоставлять объекты, которые (автоматически) рулят этим глобальным счетчиком использования DLL.
---
Частный пример — DLL сервер COM объектов.
При освобождении последнего COM-объекта, DLL должна прекращать все свои фоновые потоки. Это делается вне DllMain
---
Кстати, если я все правильно помню, у Рихтера еще в третьем издании (это ~98 год) было описана эта проблема, которую он отважно победил
O>Вникать лень но что сказать имею.
O>В винде _НИЗЗЯ_ ждать завершения потока из DllMain — это вызовет дедлок по неочевидным для простого писателя кода причинам. Это означает в том числе что нельзя ждать завершения потока в деструкторе статик объектов, которые объявлены в длл (так как эти деструкторы исполняются из DllMain).
Ага.
Общее правило, которое я выработал для себя:
У DLL должны быть функции инициализации и деинициализации. Можно (лучше) с глобальным счетчиком вызовов.
При обнулении этого счетчика, DLL должна прекратить все свои фоновые потоки.
---
Можно обойтись без этих функций.
Тогда DLL должна предоставлять объекты, которые (автоматически) рулят этим глобальным счетчиком использования DLL.
---
Частный пример — DLL сервер COM объектов.
При освобождении последнего COM-объекта, DLL должна прекращать все свои фоновые потоки. Это делается вне DllMain
---
Кстати, если я все правильно помню, у Рихтера еще в третьем издании (это ~98 год) было описана эта проблема, которую он отважно победил