NCurses не восстанавливает поведение терминала

Question

Здравствуйте, дорогой Communauts,

Я создаю отчет о терминальном анимированном состоянии для параллельного программного обеспечения, которое я разрабатываю. Я использую NCurses. У меня возникла проблема, связанная с восстановлением стандартного поведения терминала. После запуска моего программного обеспечения терминал имеет только 24 строки, независимо от того, вызываю ли я endwin(), или нет. Вот упрощенный код:

int size=10; 
initscr(); 
refresh(); 
while(KeepAlive){ 
     int j=1; 
     mvprintw(j,0,/*Blah blah header*/)); 
     for(int i=0;i<size;i++){ 
      j++; 
      mvprintw(j,0,/*Some blah blah*/); 
     } 
     refresh(); 
     usleep(1000000); 
} 
endwin(); 

KeepAlive является управляющим переменной изменена другого потока (таким образом, в то время как не бесконечный цикл, но контролируемая петли). После запуска этого программного обеспечения мой терминал имеет только 24 строки, работает эхо, но есть много свободного места.

Большое спасибо за вашу помощь, получать удовольствие

EDIT:

Я хотел бы поделиться с вами информацией, я нашел, пытаясь решить мою проблему:

1. проклятия (Ncurses) отлично работает под openMP, тогда вы можете представить, что некоторые потоки выполняют ваши математические вычисления и один поток (только один, обратите внимание), выдавая некоторую информацию о времени выполнения.
2. проклятие (ncurses) НЕ совместимо с MPI. Ну, правильная формулировка будет «не полностью» совместима с MPI. MPI действительно сложный в отношении stdin/stdout/stderr, поскольку все выходы из всех MPI-процессов могут быть перенаправлены на дисплей (который может быть указан). Использование любой расширенной библиотеки вывода с превышением вывода приведет к ошибке кода или неожиданному поведению.

, который поддерживается Справка MPI:

Может быть. Но, вероятно, нет.

Открытый MPI обеспечивает довольно сложную пересылку stdin/stdout/stderr. > Тем не менее, это не работает с проклятиями, ncurses, readline или другими сложными пакетами ввода-вывода, которые обычно требуют прямого управления терминалом.

Каждая библиотека приложений и ввода-вывода отличается - вы должны попытаться проверить, поддерживается ли ваша. Но, скорее всего, это не сработает.

Извините. :-(

найдено here (MPI reference).

То, что я обнаружил, что даже если вы назначить только один MPI-процесс управления все выходные проклятия (только этот процесс вызывает initscr() в начале и endwin() в конце его части кода) нет никакого способа заставить проклятия использовать полный терминал (только UNIX 24x80 по умолчанию будет доступен). После завершения MPI весь ваш терминал будет работать в режиме 24x80 до тех пор, пока

Спасибо всем, кто помог мне,

весело провести время

GF

Answer 1

Одно из возможных решений - полностью отделить текстовый графический интерфейс от остальной части кода MPI и заставить обе части разговаривать друг с другом через клиент/серверный механизм MPI-2. Это означает, что:

1. Запуск GUI как программа одноточечен MPI, то есть один, который вызывает MPI_Init{_thread}, но не запускается с помощью mpiexec. Затем он должен открыть порт прослушивания, вызвав MPI_Open_port. Вызов возвращает имя порта строки, которое должно быть предоставлено вычислительной части приложения. Затем часть GUI начнет прослушивать соединения, вызвав блокировку MPI_Comm_accept.

2. Вычислительная часть запускается, как обычно, через mpiexec. Он должен подключиться к GUI, вызвав MPI_Comm_connect, учитывая имя порта из (1).

3. Комбинация MPI_Comm_accept в графическом интерфейсе и MPI_Comm_connect в вычислительной части устанавливает межобщинный коммуникатор, который может использоваться для отправки сообщений между двумя частями. Вычислительная часть может, например, отправлять периодические сообщения о статусе в графический интерфейс пользователя. При необходимости интеркоммуникатор может быть далее «сплющен» до внутриобщинного.

4. После завершения вычисления часть связи должна отключиться, позвонив по телефону MPI_Comm_disconnect.

5. GUI должен позвонить MPI_Close_port и завершить свое собственное исполнение.

В этом сценарии GUI часть может быть в текстовом режиме проклинает запуск приложения локально или удаленно через SSH, приложение X11 GUI, или что-то еще там.

Answer 2

Он должен работать.Комментарий о «параллельной» предполагает многопоточность, что может означать, что ваш вывод не покраснел, как можно было бы ожидать.

Вероятно, это та же проблема (Ncurses limited output size), для которой была предоставлена ​​дополнительная информация. Ни один из вопросов не дает достаточно подробностей, чтобы предлагать больше, чем общие рекомендации.