QTcpServer with QProcess

Pepijn

Hey I am wondering if there is a way to build a QTcpServer that uses QProcess to handle new connections. I need this because I'm using a C library that has global state and is prone to end up in unrecoverable situations.

As far as I can tell from this issue at some point sockets were made to be not inheritable, meaning it would no longer be possible to access the open socket in the child process.

Is there any way to do such a thing?

I'm not sure if sockets are still inherited on Linux, because it seems there is a Windows-specific API to change the arguments to CreateProcess. Would that provide a path to make a QProcess based QTcpServer?

SGaist

Hi and welcome to devnet,

Do you mean you have a secondary application using that library that you want to execute ?

Kent-Dorfman

in linux fork() duplicates file descriptors, and since the socket API is accessed via socket descriptor, your proposed model duplicates the traditional unix/linux way to do multiple daemon connections. Whether it is supported in the Qt API is a different issue, but at the Linux system programming level, yes, it's very possible.

JonB

@Kent-Dorfman
Yes, but per the referenced https://bugreports.qt.io/browse/QTBUG-4465 it appears that Qt chooses to set the fcntl() FD_CLOEXEC flag under Linux which will prevent inheritance to exec()-ed child, and the bug report calls for Windows to pass CreateProcess() bInheritable = false to make it the same.

Pepijn

@SGaist said in QTcpServer with QProcess:

Do you mean you have a secondary application using that library that you want to execute ?

I'm not sure what you're asking. The subprocess that uses the shared library could be a different executable if needed, but the important part is that it can talk on the socket the parent process accepted, so it can stream data from the simulation library to the client, while living in its own address space.

@JonB said in QTcpServer with QProcess:

@Kent-Dorfman
Yes, but per the referenced https://bugreports.qt.io/browse/QTBUG-4465 it appears that Qt chooses to set the fcntl() FD_CLOEXEC flag under Linux which will prevent inheritance to exec()-ed child, and the bug report calls for Windows to pass CreateProcess() bInheritable = false to make it the same.

Right, and there is no mechanism to get the old default? The issue it replaces called for a InheritHandles property to be added, but as far as I can tell this never happened.

JonB

@Pepijn
There is a https://doc.qt.io/qt-5/qprocess.html#CreateProcessArgumentModifier-typedef for Windows only. The Qt docs don't seem to state what its members are. From https://code.woboq.org/qt5/qtbase/src/corelib/io/qprocess_win.cpp.html#_ZN15QProcessPrivate17callCreateProcessEPi there should be a cpargs->inheritHandles you could set/override?

However from line https://code.woboq.org/qt5/qtbase/src/corelib/io/qprocess_win.cpp.html#564 I already see true being passed for that. So.... are you really sure this does not already work? I know the bug you referenced says inheritance was switched off, but that was from 2012.....

Ah, I now see it talks about DuplicateHandle. I don't know what the Qt code does about that perhaps prior to calling CreateProcess? You should also read https://docs.microsoft.com/en-us/windows/win32/sysinfo/handle-inheritance.

I suggest you look in the code at what you claim is happening. You state

As far as I can tell from this issue at some point sockets were made to be not inheritable, meaning it would no longer be possible to access the open socket in the child process.

but I have yet to find that definitively. Are you sure, have you tested? You claim a "change" and an "old default" but have not mentioned anything about Qt versions, which you might compare/read about for this change?