> It's a side-effect. The problem is the QProcess::setupChildProcess virtual > in Qt 5, that had been there since QProcess was introduced the the > Paleolithic Era. When we use CLONE_PIDFD, we have to call clone() directly, > which means the hooks installed by pthread_atfork() do not get run. In > particular, this may mean the mutexes locked by other threads are all still > locked, including one inside malloc(). That would mean the user's code in > setupChildProcess() could deadlock depending on the kernel version.
Thanks again for clarifying this! > ... So it was simplified to "if you derive, assume setupChildProcess > was overridden." I don't know if this would be still possible for the Qt 5 docs, but a small hint like "If you subclass this, be aware that ..." woudn't hurt ... As said, I would never have thought that this would have such side-effects! Sure, Qt 6 has been out for some months now, but I think Qt 5 may be still used for quite some time. Here at Gentoo, we e.g. don't even have Qt 6 in the main package repository yet, and normally, Gentoo is not much hesitant to add new versions ... but that's another issue. > Anyway, please note that simply your problem still exists even without > subclassing on kernels older than 5.4. For those, we have to use the SIGCHLD > handler anyway. This must be fixed in the SANE backend. If you're really bored some time, maybe you want to file an issue for the SANE Pixma backend and tell the devs what exactly is wrong there and/or how to fix this? > Or you can work around it by doing what it is doing: fork(). Well, I think, if I'm safe with Qt >=5.15 and Kernel >=5.4, for now, I'd stick with the simple implementation that works now. Forking some part of a Qt program is something I even know less about than what can happen if I call external programs via QProcess ... I'm quite happy to have it in a working state now! Surely, the fact that some SANE backends may cause issues with process calls with older kernels should be mentioned in the still-to-write docs. But at the moment, I think I should first see if anybody besides me ever considers the project to be meaningful and if it would be worth it to make it safe for older environments. Although it may be worth it to mess with this stuff to learn more about process handling, threads and forks and so on. I think, first, I'll get the whole thing in shape with a program icon, installation target, message extraction script and so on. So that it _could_ be used. And then, I'll see if anybody actually wants to use it ;-)
