0

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 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 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

AVJ
  • 213
  • 3
  • 11

1 Answers1

0

The idea that you have to wait for any sort of I/O is mostly antiquated. You should design your code so that it is informed by the operating system as soon as I/O request is fulfulled (new input data available, output data sent, etc.).

You should simply use standard input for your purposes. The process doesn't have to wait for standard input, it can check if any input is available, and read it if so. You'd do it in the same place were you'd poll for changes to the shared memory segment.

For Unix systems, you could use QSocketNotifier to get notified when standard input is available.

On Windows, the simplest test is _kbhit, for other solutions see this answer. QWinEventNotifier also works with a console handle on Windows.

Community
  • 1
  • 1
Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • So my c++ executables (process 2's) stdout is already spewing data that my QApplication (process 1) is reading. If process 1 wants to send something to process 1's stdin which process 1 is checking for input, I'm assuming that the 2 streams won't interfere? (I read somewhere that since they're separate channels it won't matter), but I'll look around more to see if that's the case. – AVJ Jun 25 '15 at 21:59
  • @Anshul Why should they interfere? That would make the whole system useless. Each direction stands on its own. That's why, on Unix, the standard input and output are on separate file descriptors, for example. On Windows something functionally similar takes place, too. – Kuba hasn't forgotten Monica Jun 26 '15 at 14:32
  • Thank you, I will try the stdin approach as you mentioned. – AVJ Jun 26 '15 at 14:51