Thread: Qt GUI to executable with pipe

The best idea here would be to write a .so that contains the core functions for grabbing the page and extracting text. Then your command line app and your GUI app could both use that library, rather than having the GUI app call the command line app in the background.

Otherwise, if the command line app is interactive, you'll need to thread and fork, using multiple pipes to the subprocess in the fork, and setting up some other form of IPC between the thread and the fork. If that sounds like more of a hassle than it is worth, I agree.

However, if the command line app were not interactive -- ie, if you just gave it the URL as a parameter at invocation -- then popen() should work fine.

First, lemme repeat again that this method "is more hassle than it is worth". It is going to take you 5-10 times longer than if you just rearrange your command line app to work with an abstracted library (which may be a new thing to you, but it is worth learning, whereas learning to do this is not).

But, if you insist:

Originally Posted by gunnerone

Quick question, do I do the forking in my Qt mainwindow.cpp?

The first thing you do is try to work this out completely outside the context of your application. I cannot stress the importance of that enough. Once you have a working model, then you can try and work it into the GUI.

The first version does not have to be threaded, it can just use a fork. However, the two forks must communicate somehow. IMO, the best way to do that is via sockets: the parent fork is the server, the child which runs the subprocess is the client. Since this is a simple one to one relationship, UDP is simpler and tidier for this than TCP.

If you haven't done socket IPC before, then before work that out using completely separate client and server programs before you try a forked version. There are are other options besides sockets -- eg, you can thread and use mutexes/semaphores. That might provide a workable shortcut in the final version, but I kinda doubt it. You could also use shared mem.

Hopefully, you are starting to see why I said this is an unnecessary hassle, a poor design choice, and going to take you much longer than any other possible option.

But, if you still insist, the next model would be threaded, because you have to thread into the GUI. You cannot have blocking events going on via the server if it is part of a GUI -- you could perhaps get around the threads by using a non-blocking socket in the server, and try work that into the logic of the GUI somehow. But before you try to conceptualize that, you need to write and play with a non-blocking server. Anyway, your server thread forks a child which controls the input and output pipes of the sub-process, and connects via a socket to the parent to send and receive data. When I said before there might be a shortcut in here, if you can set up non-blocking pipes in the "server" thread, you could do without the fork and the sockets and just use mutexes with the main (GUI) process. But I am not sure how possible or feasible that is.