Possible for QSharedMemory to be shared by a QT application and a non-QT process?

I'm a QT newbie so apologies if I'm missing something basic. I have a QApplication that calls an external executable. This executable will keep running infinitely, passing data to this QApplication through stdout, unless it's manually exited from by the user running it from console. This process does not wait for stdin while it is running (it's a simple c++ code that's running as an executable that has a while loop).

I want to be able to modify this executable's behavior at runtime by being able to send some form of signal (any kind of signal, even a single byte. Not to be confused with QT's signal/slot) from the QApplication to the external process. I read about QT's IPC and I think QSharedMemory is the easiest way to achieve this. I cannot use any kind of pipes etc since the process is not waiting for stdin.

Is it possible for there to be a QSharedMemory that is shared by the QApplication as a well as a process running externally that is not a QT application. If yes, are there any example someone can point me to; I tried to find some but couldn't. If not, what other options might work in my specific scenario?

Thanks in advance

EDIT: Just to be more clearer, I want to be able to modify the executable's behaviour by making it do other things, than what it's doing at a given time. This can probably be achieved by sending a number or a char that specifies something. The QApplication can close this executable through QProcess so that is not required to be done by sending any signal. If I use stdin of the executable to listen to the signal sent by the QApplication, will it interfere with the stdout of that executable which is being read by the QApplication? I presume not, since they're separate channels, but just wanted to be sure.

How does the user running it from the console cause it to exit? Ctrl C?

It strikes me that if you have access to change the other application to watched shared memory then you can make it listen on stdin for a magic drop-dead signal (that a user would not type by accident), watch for a specific file to appear signifying that it should close, or use QLocalSocket to talk to a named pipe/socket.

Either ctrl+C or ESC can exit the application. That is purely for debugging purposes. When both sides are perfected I won't need user input for anything on the c++ executable side. I will need the stdout of that process though, since my QApplication reads from stdout of that executable. I'm guessing if I use stdin of that executable to receive signals from the QApplication, it won't interfere with stdout of that executable since they're separate channels? I was just reading about that to make sure that is the case. I will look at QLocalSocket to see if I can use that to send signal to the stdin of the executable.

QSharedMemory is just an API around the system's shared memory facility, the memory controlled by that is not Qt specific.

QLocalSocket is for system and even user local socket communication. It has nothing to do with stdin.

To write to a child program's stdin, just use the respective QProcess API.

Cheers,
_