Как вы можете ждать отдельных потоков или контролировать, как потоки создаются?

Question

Когда вызывается spawn, возвращается JoinHandle, но если этот дескриптор отбрасывается (или недоступен где-то внутри ящика), поток «отсоединяется».

Есть ли способ найти все запущенные потоки и восстановить для них JoinHandle?

... у меня такое ощущение, что в общем случае ответ отрицательный.

В таком случае, есть ли способ переопределить, как вызывается Thread, или как глобально отбрасывается JoinHandle?

... но, просматривая источник, я не могу понять, каким образом это возможно.

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

Я приму любой ответ:

• демонстрирует, как восстановить JoinHandle любыми возможными способами
• демонстрирует, как каким-то образом переопределить поведение thread::spawn(), так что отброшенный JoinHandle из потока, вызванного в какой-либо произвольной подфункции, может быть восстановлен до его отбрасывания.

Answer 1

Есть ли способ найти все запущенные потоки и восстановить для них JoinHandle?

Нет, это, вероятно, наложит ограничения / накладные расходы на каждого , кто хочет использовать потоки, что является противоположностью для языка системного программирования.

Вы можете написать собственное решение для этого, используя что-то вроде Arc / Weak и глобальный синглтон. Тогда у вас есть собственный реестр тем.

есть ли способ переопределить то, как вызывается Thread, или как глобально отбрасывается JoinHandle?

Нет, это невозможно сделать с библиотеками Rust, поскольку они существуют сейчас. Фактически «переопределение» чего-либо в этом масштабе довольно противоречит понятиям статически скомпилированного языка. Представьте, что любая используемая вами библиотека может решить "переопределить", как работает сложение или что делает println Некоторые языки do допускают такой динамизм, но это обходится дорого. Руст не подходит для этого.

На самом деле, правильное решение для этого не является чем-то новым: просто используйте внедрение зависимостей. «Начало потока» является нетривиальным соавтором и, вероятно, не относится к сфере компетенции большинства библиотек, поскольку это ресурс для всего приложения.

можно восстановить до того, как его уронят

В Rust значения отбрасываются в конце области, где они использовались в последний раз. Это потребует запуска произвольного кода на прологе произвольных функций в любом месте программы. Такая функция вряд ли когда-либо будет реализована.

---

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