I am creating a program in ncurses that displays a list of songs on the screen. The user selects which song he wants and hits enter to play it. This program is piping to mpg321 in order to play the song. I create a thread to view the output of mpg321 and wait for the song to end so the program can go to the next song.

The problem is that the thread cannot directly manipulate the screen for some reason. This is the relevant code for the thread:

for (;
{
z=0;
read(stat_pipe[0], tempbuff, 1);
while (tempbuff[0] != '\n')
{
statbuff[z]= tempbuff[0];
statbuff[z+1]= '\0';
z++;
tempbuff[0]= '\0';
if (z > 49) break;
read(stat_pipe[0], tempbuff, 1);
}
if ((strcmp(statbuff, "@P 0")) == 0) /*Song has ended*/
{
menu_driver(my_menu, REQ_DOWN_ITEM);
cur_item= current_item(my_menu);
play(item_description(cur_item));
}
}

The description of the item is the name of the song which is then piped to mpg321. The problem is that the selector on the item doesn't move down on the screen. However, the next song is played (unless you're on the last song, but that is expected behavior). My second idea was to inform the main thread in some way that a song has ended, so the main thread can do the menu work, but the main thread is blocked at getch() waiting for user input.

Wow... are there really people in the world who program in good old ncurses? This is typically one of those last little things which cost you a week or so to solve.

Now I have written multithreaded programs which used ncurses, but I always had only one thread accessing the screen. And it is quite some time ago that I wrote any c code at all, but let's try:

Apparently the current item is updated. You request it, and use it to select the next song, correct? That means that the menu itself is handled correctly, but that the screen update is postponed for some reason.

Have you tried to issue an explicit window refresh?

So to see you are using the menu without an associated window. Have you tried to associate a window with the menu and issue an explicit refresh?

To debug, you could start gdb in a different terminal, and attach to the main thread, and set a breakpoint in the screen refresh routine of ncurses. The second thread would just continue to run, but your program would stop in the debugger when the breakpoint is hit. You then could see if the refresh function is not called at all, or refuses to refresh for some reason.

If this all fails, you could make getch() non-blocking in the main loop in your main program. Then you could use a variable to signal when a track is finished, and advance the menu pointer. But then, you would not need the multi-threaded approach at all.

That would be a pity because this multi-threaded approach is quite elegant.

jlinkels

There is only one window in the app, stdscr. I have tried an explicit refresh, but no dice. Here's another odd thing I didn't notice before: say it has moved down three songs in the list since the user hits enter. The cursor is still over the original song. However, once the cursor is moved up or down, it will jump to the actual position of the cursor with one space moved up or down, respectively.

The idea of having getch be nonblocking sounds good to me, and it would remove the extra complexity of the thread. I just need to figure out how to make getch nonblocking, but I can find out real quick. The only real reason for using the thread was because of a precursor to the program I'm making, which implemented a thread.

This is sounding more like a bug in ncurses than a bug in my program. Doing a little more playing around, it seems like ncurses has problems with multiple threads. I moved the part of the program that getches into the thread and the part seen above in the main thread. Strangely enough, getch couldn't read from any of the keys EXCEPT for the function keys (F1, F2....). I'm thinking I may want to complile this on a FreeBSD machine I have, since FreeBSD handles threads differently than does Linux.