Connecting with QProcess to an already running process

[high_flyer]

Hi All,

Is it possible to connect with QProcess to an already running process?
I could not find that option in the docs, but I would expect this to be possible by giving QProcess the ID of the process I want to attach to?
Is this possible?
If not, is there another way to do this?
(under linux)

Thanks in advance-

[wysota]

I wouldn't expect it to be possible, because if you want to read to stdin or read from stdout of an application, you need to have access to its streams and to do that you have to be in its process group (or something like that, don't remember the actual name), in the easiest case be its parent (process that calls execve to start the app can first dup2() its descriptors).

GDB somehow manages to attach to a running application, but I suspect it uses some special means to achieve that.

Edit: Of course it might be possible using some dedicated kernel module or something, but it's probably not what you are looking for.

[high_flyer]

Hmm... ok thanks for that.
And actually its is the connection to the stdin/stdout connection what I am interested in.

Too bad, could have been a nifty solution.

[wysota]

If you can make a specially crafted shell (or other process) start the process in question, maybe you could use pipes to communicate with the application. But I wouldn't count on doing that with any process.

[high_flyer]

That would be too much work for that.
The idea was to start minicom from a Qt application and use that to read and write from the serial port.
Since it is possible to start and detach the process, we were hoping that in case the Qt application crashes, it could be restarted, and let QProcess "re connect" it self to the already running minicom instance that was started in the previous run.

We will have to weigh our needs to select the proper design.

Thanks!

[wysota]

It should be quite easy to do what you want if you used a kind of proxy between the detached process and minicom. Minicom should start a wrapper that would in turn start the target application and create two named pipes. Then if the Qt app crashes, it could spawn another wrapper (though the terminal again) and it could reuse the already existing pipe to the original wrapper to communicate with the app. A little overhead with using those wrappers, but it should work.

[high_flyer]

Minicom should start a wrapper

Do you mean with the -S option?
That is the only way I could find in the docs that allows minicom to run something else.

Then if the Qt app crashes, it could spawn another wrapper (though the terminal again)

Could you explain how this would work?
I don't follow, how the crashing application can spawn a new instance of it self (if this is what you mean)
Or do you mean minicom should spawn a new instance of the wrapper, but even then I don't quite follow...

Thanks for the advice!

[wysota]

Do you mean with the -S option?
That is the only way I could find in the docs that allows minicom to run something else.

I have no idea about how to perform it - it's just a thought. But the wrapper can always be called instead of running the final program.

Could you explain how this would work?
I don't follow, how the crashing application can spawn a new instance of it self (if this is what you mean)
Or do you mean minicom should spawn a new instance of the wrapper, but even then I don't quite follow...

The wrapper would start the target application and duplicate its stdin and stdout and create named pipes to it. Then if the app at the other end of the terminal crashed, the wrapper would keep running. Then if the app was restarted, it could start a wrapper again that would see that named pipes are already created and communicate through them. The downside is that you have two wrappers instead of one, but this could probably be worked around as well. The wrapper could even be a daemon which you would connect to from your Qt app (using the minicom) that would always be connected to the target app.

These are just thoughts - they need to be extended into a working solution, but I think the idea is reasonable - you might say that i.e. ssh servers work more or less like that, they just terminate the shell if you terminate connection.