Как я могу надежно очистить потоки ржавчины, выполняя блокировку IO?

Question

Вроде бы общие идиомы в Русте порождалась нитью для блокировки ввода-вывода, так что вы можете использовать неблокирующие каналы:

use std::sync::mpsc::channel; 
use std::thread; 
use std::net::TcpListener; 

fn main() { 
    let (accept_tx, accept_rx) = channel(); 

    let listener_thread = thread::spawn(move || { 
     let listener = TcpListener::bind(":::0").unwrap(); 
     for client in listener.incoming() { 
      if let Err(_) = accept_tx.send(client.unwrap()) { 
       break; 
      } 
     } 
    }); 
} 

Проблема, присоединяясь темами, как это зависит от породившей нити «реализация "что приемный конец канала уронили (т.е., вызов send(..) возвращается Err(_)):

drop(accept_rx); 
listener_thread.join(); // blocks until listener thread reaches accept_tx.send(..) 

Вы можете сделать фиктивные соединения для TcpListener с, и отключение TcpStream сек через клона, но они, кажется, как на самом деле Hacky способы очистки таких читает, и в его нынешнем виде я даже не знаю об ошибке hack, чтобы вызвать блокировку потока при чтении от stdin.

Как я могу очистить такие темы, или моя архитектура просто не так?

Answer 1

tldr; Фиктивная связь может быть самым простым способом.

(я предполагаю, что Linux в качестве ОС.)

listener.incoming() будем называть Признавайте() на TcpListener в .next() метод и нить будет застрял в принять вызов к Операционные системы. Он может, насколько мне известно, только добровольно возвращаться в результате попытки подключения или сигнала или если сокет установлен неблокированным.

Обработка сигналов, похоже, не поддерживается стандартными библиотеками ржавчины.

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

Альтернативой может быть использование mio, поскольку оно обеспечивает цикл событий. Вы могли бы либо адаптировать все ваше приложение к циклу событий, и не нуждаться в делать потоки, или вы могли бы использовать цикл событий для каждого потока, который мог бы блокировать и позволить ему прослушивать дополнительный канал, чтобы вы могли его разбудить что он может закрыть себя. Первый, возможно, не выполнит больше, в зависимости от того, как много кода у вас уже есть, а второй - переполнения.

Answer 2

Просто невозможно безопасно отменить поток в Windows или Linux/Unix/POSIX, поэтому он недоступен в стандартной библиотеке Rust.

Here is an internals discussion about it.

Есть много неизвестных, которые возникают из-за принудительного отмены потоков. Это может стать действительно грязным. Кроме того, комбинация потоков и блокировки ввода-вывода всегда будет сталкиваться с этой проблемой: вам нужно, чтобы каждый блокирующий вызов ввода-вывода имел тайм-ауты, чтобы даже иметь возможность быть прерываемым надежно. Если не удается написать асинхронный код, нужно либо использовать процессы (которые имеют определенную границу и могут быть принудительно завершены ОС, но, очевидно, имеют более тяжелый вес и проблемы с совместным использованием данных) или неблокирующий ввод-вывод, который будет переместите свой поток обратно в цикл событий, который прерывается.

mio доступен для асинхронного кода. Tokio - это ящик более высокого уровня на основе mio, который делает запись неблокирующего асинхронного кода еще более прямым.