libksane seems to break QProcess::start calls

[Tobias Leupold]

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