Thread: Ncurses and multiple processes

It is just regular IPC. ncurses uses an event loop which makes running a local socket server for the app easy.

Glib has some functions to make that easier still:

IO Channels

eg, you can register a socket descriptor with a callback that runs whenever there is data to read.

To clarify, that means making the "ncurses server" it's own app and then the other processes just send it data to handle.

Or you could use threads.

Originally Posted by The Jar

Thanks. It makes sense what you are saying. However I still wonder if there is a chance that two application can talk to the same ncurses window without using IPC or any external application.

I don't see where MK27 is using an external application, just suggesting IPC and threads. The 'socket server' is just an application design function. Is there a reason not to use IPC? As for just "using" ncurses, even if you create the essential window handles ahead of time (and why the fork() vs a thread? fork() is pretty ham-handed unless you have a really good reason for using it) and hand them out to the processes you have created, I doubt there is any guarantee of thread/process safety here.

Thus if you have a main thread to "own" the windowing code/handles, spin off a second thread to do some work and then update it's portion of the screen by using IPC (socket or built-in messaging) to tell the main thread to "update my portion of the screen like so..." it would seem to accomplish your mission.

Originally Posted by The Jar

Thanks. It makes sense what you are saying. However I still wonder if there is a chance that two application can talk to the same ncurses window without using IPC or any external application.

Even if you could do this, you wouldn't want to. Having multiple processes/threads updating the same window will cause all sorts of problems unless you synchronize access between them. And synchronizing access would require IPC of some sort, so it pretty much invalidates your requirement of not using IPC.