Unix Programming - Curses and child processes

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > April 2004 > Curses and child processes





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Curses and child processes
Doug Ly

2004-04-28, 10:34 am

Hi,
I have a shared memory of curses window structure so every child process can
write into that window. Then in my program I fork a few children and have
them write into that window.

The output is weird. It only displays output of 1 process. After the
process gets terminated, the window is erased and the output of new process
is displayed.
What I would like to do is to have all the processes' outputs displayed in
that shared window without being erased.

Here is the piece of code

// get shared memory location for curses window
shm_win = shmget( 111222333 , sizeof(struct _win_st), 0666 | IPC_CREAT );
w2 = (WINDOW*) shmat( shm_win, 0, 0);

// init the screen and window
initscr();
w2 = newwin(10,50,8,2);
scrollok(w2,TRUE); // set scrollable
idlok(w2,TRUE);

for ( int i = 0 ; i < 10 ; i++)
{
if ( fork() == 0 )
{
// assuming that x is a shared memory for an integer holding
y-position of text.
mvwprintw(w2,*x,2, "Blah");
(* x)++;
wrefresh(w2);
sleep(1);
_exit(0);
}
}

for ( int i = 0; i < 10; i++)
wait(0);


Thanks a lot


Fletcher Glenn

2004-04-28, 5:34 pm



Doug Ly wrote:
> Hi,
> I have a shared memory of curses window structure so every child process can
> write into that window. Then in my program I fork a few children and have
> them write into that window.
>
> The output is weird. It only displays output of 1 process. After the
> process gets terminated, the window is erased and the output of new process
> is displayed.
> What I would like to do is to have all the processes' outputs displayed in
> that shared window without being erased.
>
> Here is the piece of code
>
> // get shared memory location for curses window
> shm_win = shmget( 111222333 , sizeof(struct _win_st), 0666 | IPC_CREAT );
> w2 = (WINDOW*) shmat( shm_win, 0, 0);
>
> // init the screen and window
> initscr();
> w2 = newwin(10,50,8,2);
> scrollok(w2,TRUE); // set scrollable
> idlok(w2,TRUE);
>
> for ( int i = 0 ; i < 10 ; i++)
> {
> if ( fork() == 0 )
> {
> // assuming that x is a shared memory for an integer holding
> y-position of text.
> mvwprintw(w2,*x,2, "Blah");
> (* x)++;
> wrefresh(w2);
> sleep(1);
> _exit(0);
> }
> }
>
> for ( int i = 0; i < 10; i++)
> wait(0);
>
>
> Thanks a lot
>
>


With multiple processes accessing the same (shared) memory, you're going
to have the same problems that you would have if your program were
multithreaded. AFAIK, the (n)curses library is not thread-safe. I
doubt that you could make this work unless you applied some type
of interprocess locking for access to the curses window.

--

Fletcher Glenn

Marc Rochkind

2004-04-30, 12:34 am

"Fletcher Glenn" <fletcher@removethisfoglight.com> wrote in message
news:40901A65.9050509@removethisfoglight.com...
>
>
> Doug Ly wrote:
can[vbcol=seagreen]
have[vbcol=seagreen]
process[vbcol=seagreen]
in[vbcol=seagreen]
IPC_CREAT );[vbcol=seagreen]
>
> With multiple processes accessing the same (shared) memory, you're going
> to have the same problems that you would have if your program were
> multithreaded. AFAIK, the (n)curses library is not thread-safe. I
> doubt that you could make this work unless you applied some type
> of interprocess locking for access to the curses window.
>
> --
>
> Fletcher Glenn
>


Yeah... Fletcher is on the right track. I did something like this (for an
example that didn't make it into the book), splitting the screen into two
windows. The first showed file names resulting from a simple text search,
and the second showed the contents of a selected file. Each window had its
own thread, so that you could start viewing files while the search was still
going on.

I assumed, as Fletcher suggested, that Curses was not thread safe and simply
encapsulated the Curses calls in an set of functions that used a mutex to
force only one thread to be in Curses at a time. Maybe I could have relaxed
the synchronization for some Curses functions, but I didn't bother. The
program worked fine, with almost no debugging troubles due to the multiple
threads.

It was supposed to be a super-duper example showing threads, Curses, and
file I/O, but it turned out to be too lengthy, and I wasn't sure that Curses
was worth it. So, I included a much simpler Curses example, and some
different thread examples. I actually used the utility quite a bit, however,
mainly for looking for symbols inside headers.

--
Marc Rochkind
"Advanced UNIX Programming" (publishing April 2004)
www.basepath.com/aup


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com