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

R>>>Ну хорошо, допустим функцию инициализации для процесса можно заменить ленивой инициализацией, заплатив дополнительной проверкой на основном пути. Допустим, функцию деинициализации для процесса можно вообще опустить, или зарегистрировать atexit(). Допустим инициализацию для потока можно тоже сделать ленивой. НО КАК БЫТЬ С ДЕИНИЦИАЛИЗАЦИЕЙ ДЛЯ ПОТОКА?
N>>Деинициализировать при выходе, почему бы нет?;)) Сделать булевский флаг...
R>Как отловить момент завершения потока?

R>Ну хотя сейчас я уже знаю:
R>http://www.rsdn.ru/forum/message/2895408.1.aspx

Автор: remark
Дата: 29.03.08

Как завершается тред? Если форсированным убийством без права пискнуть, то всё плохо по-любому. Если обычным путём, управляемым средой языка (return или исключение), то достаточно объекта со счётчиком и логикой "init/deinit только на переходах счётчика между 0 и 1", устанавливаемого в тред в стиле RAII.

N>>Ну или разрешить многократную инициализацию и деинициализацию.

R>Если я правильно понял, то речь не об этом. Речь о том, как инициализировать/деинициализировать ресурсы, выделенные для конкретного потока, а не глобальные.

О выполнении init/deinit в контексте именно данного треда, насколько я понимаю, заботится библиотека.

R>>>Как ты предлагаешь делать? Не освобождать ресурсы, связанные с потоком? А если приложение создаёт и рушит по 100 потоков в секунду?
N>>А это вообще диверсия (если речь не идёт про явно специализированные случаи типа эрланга). Используйте пулы тредов.;)
R>Т.е. предлагаешь не инженерное решение, а организационное — автор библиотеки должен постоянно обходить всех клиентов и говорить "Используйте пулы тредов. Пожалуйста." :)))

Ему как раз пофиг. Не пофиг — автору конечной программы.