NCurses not restoring terminal behavior

问题:

Hello dear Communauts,

I'm am creating a terminal animated status report for a parallel software I'm developing. I'm using NCurses. I'm having an issue related to the restoring of the standard behavior of the terminal. After running my software the terminal keeps having just 24 lines, no matter if I call endwin() or I don't. Here the simplified code:

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 is a control variable changed by another thread (so the while is not infinite loop, but controlled loop). After running this software my terminal has only 24 lines, echo works, but there's plenty of blank space.

Thanks a lot for your help, have fun

EDIT:

I would like to share with you some information I found while attempting to solve my issue:

1. curses (ncurses) is perfectly working under openMP, then you can imagine some threads doing your math calculations and one thread (only one, be aware) giving out some runtime infos.
2. curse (ncurses) is NOT compatible with MPI. Well, the right stating would be is "not completely" compatible with MPI. MPI is really sophisticated about stdin/stdout/stderr, since all outputs from all MPI-processes could be redirected to a display (which could be specified). Using any advanced terminal output overriding library will take to a fault of the code, or unexpected behaviors.

That's supported by the MPI faq:

Maybe. But probably not.

Open MPI provides fairly sophisticated stdin / stdout / stderr forwarding. >However, it does not work well with curses, ncurses, readline, or other >sophisticated I/O packages that generally require direct control of the terminal.

Every application and I/O library is different -- you should try to see if yours >is supported. But chances are that it won't work.

Sorry. :-(

found here (MPI reference).

What I've discovered is that even if you appoint only one MPI-process to manage all the curses output (just that process calls initscr() at the beginning and endwin() at the end of his part of code) there is no way to force curses to use the full terminal (only default UNIX 24x80 will be available). Once MPI has been finalized your whole terminal will keep working in 24x80 mode until reset is called.

Thanks to all communauts that helped me,

Have fun

gf

回答1:

One possible solution is to completely decouple your text GUI from the rest of the MPI code and make both parts talk to each other via the client/server mechanism of MPI-2. That means:

1. Run the GUI as singleton MPI program, i.e. one that calls MPI_Init{_thread} but is not started via mpiexec. It then should open a listening port by calling MPI_Open_port. The call returns a string port name that has to be supplied to the compute part of the application. The GUI part should then start listening for connections by calling the blocking MPI_Comm_accept.

2. The compute part is started as usual via mpiexec. It should connect to the GUI by calling MPI_Comm_connect given the port name from (1).

3. The combination of MPI_Comm_accept in the GUI and MPI_Comm_connect in the compute part establishes an intercommunicator that can be used for sending messages between the two parts. The compute part could e.g. send periodic status messages to the GUI. If necessary, the intercommunicator could be further "flattened" to an intracommunicator.

4. Once the computation is finished, the communication part should disconnect by calling MPI_Comm_disconnect.

5. The GUI should call MPI_Close_port and finish its own execution.

In that scenario, the GUI part could be a text mode curses application started locally or remotely via SSH, an X11 GUI application, or whatever else there.

回答2:

It should work. The comment about "parallel" suggests multithreading, which can mean that your output is not flushed as one might expect.

Likely this is the same issue (Ncurses limited output size) for which more information was given. Neither question provides enough detail to offer more than generic advice.