Developing.ru

Absurd писал(а):В общем случае background thread встречается в публикациях в два раза чаще, чем secondary thread

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

Absurd писал(а):Я кажется понял что ты называешь первичным потоком - это тот поток который был создан в результате выполнения CreateProcess. Но он ничем не отличается от других потоков. Есть мнение что завершение этого "первичного" потока завершает работу программы, но оно ошибочно. ОС удаляет процесс когда _все_ треды программы завершили свою работу. Она их не отличает друг от друга. Но есть такой ньанс что все треды убиваются библиотекой C Runtime после выхода из функции main()/WinMain().

А она в первичном потоке. То есть при завершении первичного потока прибиваются вторичные и завершается весь процесс. Что и требовалось доказать. А что небольшая техническая задержка возникает и фактическое закрытие происходит, когда ОС выполнит принудительное завершение вторичных потоков, так это иначе просто фиг реализуешь. Если бы потоки не различались, то процесс продолжался бы и после завершения main/WinMain, пока все функции вторичных потоков не выполнят return. А ещё, не все потоки имеют очереди сообщений.

Но есть такой ньанс что все треды убиваются библиотекой C Runtime после выхода из функции main()/WinMain().

А она в первичном потоке. То есть при завершении первичного потока прибиваются вторичные и завершается весь процесс.

Нет, при компиляции с поддержкой мультитредовости все треды равнозначны. C Runtime создает индивидуальный экземпляр всех своих структур для каждого треда при помощи thread local storage. Это происходит в функции _beginthreadex.

Если бы потоки не различались, то процесс продолжался бы и после завершения main/WinMain, пока все функции вторичных потоков не выполнят return.

Это нормальное и логичное поведение системного сервиса. "Первичный" поток зарегистрировал RPC и завершил свою работу. Теперь работают только "вторичные" потоки, которые будут обслуживать RPC вызовы. Завершение процесса при этом не происходит.

Что важней: сохранение жизни экипажа, или экономия топлива? Конечно не до жиру, быть бы живу. А ситуация вдруг сложилась так, что экономить топливо нужно именно для того, чтоб сохранить жизнь экипажа? Тогда его будут экономить всеми возможными способами. А теперь вопрос: как поведёт себя система, если быстрое исполнение среднеприоритетного потока нужно для быстрой работы малоприоритетного, а процессорное время ждёт ещё десятка два потока с почти высшим приоритетом?

Ты затрагиваешь тему на которую написана куча докторских диссертаций и патентов. Хорошего решения не знает никто, над работающими решениями трудятся доктора наук, плохое решение приносит убытки на миллиард евро.

Romeo писал(а):Мне тоже это Эй Си всегда было непонятно...

В середине второй страницы я нашел нечто похожее - Allied Chat в командных играх типа Dota и Left 4 Dead. Значит примерно "ладно, здесь все свои".