Краткий ответ

Завершение основного потока само по себе не останавливает обычный не-daemon поток. Процесс Python продолжит работу, пока такой поток не завершится; интерпретатор завершает процесс только после окончания всех живых не-daemon потоков.

Исторический контекст

Модель потоков предназначена для выполнения фоновой или параллельно ожидающей работы внутри одного процесса. Поэтому жизненный цикл процесса отделён от жизненного цикла основного потока: завершение функции main не означает немедленную остановку всех рабочих потоков.

Для фоновых задач существует режим daemon. Он позволяет не удерживать процесс после завершения основных задач, но ценой отсутствия гарантированного завершения работы и корректного освобождения ресурсов.

Постановка проблемы

Если рабочий поток заблокирован на чтении из сокета, ожидании очереди или бесконечном цикле, основной поток может завершиться, а процесс останется жить. В сервере это приводит к зависанию завершения, а в тестах — к незавершённым процессам и зависшим пайплайнам.

Обратная ошибка — бездумно сделать поток daemon. Тогда процесс может завершиться в любой момент, пока поток записывает данные, удерживает транзакцию или выполняет освобождение ресурса.

Подробное решение

Не-daemon поток удерживает процесс до своего завершения. Основной поток может вызвать join, чтобы явно дождаться конкретного рабочего потока, но сам факт завершения основного потока не выполняет автоматическую остановку рабочих потоков.

Корректный шаблон завершения — передать потоку сигнал остановки, дать ему выйти из цикла и затем вызвать join с разумным тайм-аутом. Для этого часто используют threading.Event: поток периодически проверяет событие или ожидает его с тайм-аутом.

Daemon-поток не удерживает процесс. При завершении интерпретатора его работа не должна рассматриваться как гарантированно завершённая: поток может не успеть закрыть файлы, отправить данные или выполнить финализацию.

join не прерывает поток и не отменяет выполняемую функцию. Он только блокирует вызывающий поток до завершения целевого потока или до истечения заданного тайм-аута. Если после тайм-аута поток всё ещё работает, его состояние нужно проверить отдельно.

Ситуация из практики

Фоновый поток сервиса читает сообщения из очереди. После получения сигнала остановки основной поток сразу завершается.

Вариант с daemon-потоком быстро завершает процесс, но может потерять сообщение, находившееся в обработке. Вариант с бесконечным ожиданием без сигнала остановки надёжен для сохранения работы, но способен навсегда задержать остановку из-за зависшего источника данных.

Выбранное решение — не-daemon поток, Event для остановки и join с тайм-аутом. Поток периодически проверяет событие, корректно освобождает ресурсы и завершает работу; если внешний ресурс не отвечает, приложение фиксирует проблему и применяет отдельную стратегию аварийного завершения.

import threading
import time

def worker(stop):
    while not stop.wait(0.5):
        process_one_item()

def process_one_item():
    time.sleep(0.1)

stop = threading.Event()
thread = threading.Thread(target=worker, args=(stop,))
thread.start()
stop.set()
thread.join(timeout=2)

Здесь поток является обычным не-daemon потоком, поэтому процесс не завершится до его окончания. Вызов stop.set() будит ожидание, после чего поток выходит из цикла; join даёт основной части программы дождаться завершения.

Что кандидаты часто упускают

Можно ли принудительно остановить выполняющийся поток стандартными средствами threading?

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

Что означает join(timeout) для жизненного цикла процесса?

Он только ограничивает время ожидания вызывающего потока. Если целевой не-daemon поток не завершился, процесс всё равно продолжит жить после возврата из join; тайм-аут не превращает поток в daemon и не отменяет его работу.

Почему daemon-поток особенно опасен для записи данных?

Потому что при завершении процесса поток может быть остановлен без выполнения прикладной логики завершения. Буфер может не попасть на диск, сообщение — не подтвердиться, а блокировка — не освободиться ожидаемым способом. Поэтому daemon-потоки подходят только для работы, потеря которой допустима, например для необязательного фонового мониторинга.