Standard I/O streams of non-kLIBC based processes are not properly redirected

[Dmitry A. Kuminov]

If QProcess starts an application that isn't based on the same (kLIBC) runtime as Qt4 itself, its standard streams are not properly redirected and cannot be accessed in the parent process.

This needs to be fixed. See #69 for more info.

[Silvan Scherrer]

i really hope we find a solution to this beside changing everything to native pipes. as i guess this would make a lot of work and it's less Qt standard like. fixing klibc maybe?

[Dmitry A. Kuminov]

I will invest some time into this after the beta. See my comment in #71 too.

[Dmitry A. Kuminov]

socketpair inheritance example

[Dmitry A. Kuminov]

The attached program proves that inheritance of sockets created with socketpair() is broken in the current kLBC (0.6.3). No matter if we use stdio redirection (parent.exe started w/o arguments) or pass fd to child.exe in arguments (parent.exe started with any argument), child.exe sometimes fails to write to the stdout stream with the following error (approximately on every 10-20'th run):

CHILD ERROR: write: Socket operation on non-socket (38)

and nothing appears on the parent's end of the pipe.

This really looks like a deadlock. Studying kLIBC sources...

[Dmitry A. Kuminov]

By deadlock I mean race condition of course.

[Dmitry A. Kuminov]

I have no idea why the related comments went to ticket:72, but just for the record. The stdio redirection in QProcess seems to work well now. What about error 38, it disappears in my virtualized environment after I increase the child startup timeout in kLIBC. See ticket:72 (especially comments 17) for more details. This timeout question will be further tracked in this defect.

[Dmitry A. Kuminov]

That may be related to the fact that the windowed console output is really slow in OS/2 and either mplayer/smplayer may not expect such big delays. Let's keep an eye on that problem. If it's something different, it'll show up and we will look at it again.

[Dmitry A. Kuminov]

Argh, I just realized that all the LIBC socket/pipe hassle was in vain. Sh*t, I already knew that but something prevented me from thinking this up to the end.

We will have to use native pipes because otherwise only stdio of kLIBC-based applications may be redirected: programs using other libraries know nothing about kLIBC file descriptors, their inheritance and redirection. While native pipes operate on native file handles and thus always work. Too pity but at least we learned a lot of useful information about kLIBC which will help us later.

Starting to code the native pipe way.

[Dmitry A. Kuminov]

BTW, I've done some stress tests using kLIBC socket redirection (child reads a 29 MB file and writes it to stdout, parent reads it and writes back to the file): no distortions and the speed is within the limits.

[Dmitry A. Kuminov]

Done with native pipes in r197. It now works as expected: standard streams of all programs (e.g. cmd.exe) are now properly redirected. I'll do a bit of stress testing tomorrow++ before closing this defect.

[Dmitry A. Kuminov]

Cool, smplayer started working (i.e. is able to control mplayer playback now) immediately after this change.

The only thing that differs from the standalone mplayer runs (which are I remind jerky under VirtualBox?) is the flicker when the video goes to the Qt window. And also an attempt to close the GUI now gives this:

Debug: Core::stopMplayer: Waiting mplayer to finish...

Warning: QMutex::lock: Deadlock detected in thread 1

Looks like a non-recursive mutex is called recursively in smplayer code.

[Dmitry A. Kuminov]

This is actually a QProcess fault, will fix it.

[Silvan Scherrer]

ok great. as smplayer worked with older QProcess also for me i will wait till you fixed the above error. After that i will build Qt also new and try with my smplayer.

[Dmitry A. Kuminov]

The deadlock is fixed in r198 (I optimized the code so it doesn't need a lock at all in that place).

[Dmitry A. Kuminov]

Feeding data to the process' standard input stream now works (r203). BTW, I've created source:/tests to store various Qt4 testing applications (such as the one for QProcess).

[Dmitry A. Kuminov]

Implemented QProcess->QProcess redirection (took a while to test, debug and fix oddities).

Now I consider this task to be done. Functionally wise, we are as good as other platforms.