Вопросы Теги

Почему предельный размер стека Linux настолько мал на 64 -битных машинах?

Если у вас есть терминал, совместимый с xterm, вы можете попробовать переключиться на альтернативный (iv )экран e с помощью Termion:

use termion::screen::AlternateScreen;
use std::io::{Write, stdout};

fn main()
{
    {
        let mut screen = AlternateScreen::from(stdout());
        write!(screen, "Writing to alternat(iv)e screen!").unwrap();
        screen.flush().unwrap();
    }
    println!("Writing to main screen again.");
}

Из Rust docs :termion ::screen

Когда вы переключаетесь обратно, все, что вы написали, исчезает. Переключение выполняется с помощью escape-последовательностей, подобных упомянутым здесь:StackOverflow :переключения на альтернативный экран в сценарии bash . Конечно, это означает, что вам не нужна эта библиотека.

-1
12.10.2021, 08:42
1 ответ

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

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

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

1
12.10.2021, 19:10

Теги

Похожие вопросы