Move the QProcessPrivate channel buffers into QProcessPrivate::Channel

Simplifies the code.

Change-Id: I70b26af69332f364d856042f114c37a70504d66f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Move the QProcessPrivate Windows objects into QProcessPrivate::Channel

Similar to the previous commit, this simplifies the code.

Change-Id: Ia02b9b5174b4bc6fd04ec2534231b7db5fc914fa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Rename QProcessPrivate::destroyChannel to closeChannel

The QProcessPrivate::Channel object contains some structures that may
survive the closing of the pipe, so calling this function "destroy" is
incorrect. Let it be just the closing.

For symmetry, the createChannel() function is renamed to openChannel().

Change-Id: I2899214c6e4c25835390b10ccf3931315a91589e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
QProcessPrivate: merge the functions dealing with stdout and stderr

Simplifies the code.

Change-Id: I4b3a6e725eb245d3531d1d11d959fb3b85862778
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Don't try to read from invalid file descriptors in QProcess

strace reveals that we do ioctl(-1, FIONREAD) and get EBADF. The only
case where this could happen is inside _q_processDied, which calls the
read functions without checking if the pipe is still open.

Change-Id: I67637fc4267be73fc03d40c444fdfea89e1ef715
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
QProcess: Handle spurious socket notifications for stdout and stderr

On Unix systems where the GUI event dispatcher uses a notification
system for socket notifiers that is out of band compared to select(),
it's possible for the QSocketNotifier to activate after the pipe has
been read from. When that happened, the ioctl(2) call with FIONREAD
might return 0 bytes available, which we interpreted to mean EOF.

Instead of doing that, always try to read at least one byte and examine
the returned byte count from read(2). If it returns 0, that's a real
EOF; if it returns -1 EWOULDBLOCK, we simply ignore the situation.

That's the case on OS X: the Cocoa event dispatcher uses CFSocket to get
notifications and those use kevent (and, apparently, an auxiliary
thread) instead of an in-thread select() or poll(). That means the event
loop would activate the QSocketNotifier even though there is nothing to
be read.

Task-number: QTBUG-39488
Change-Id: I1a58b5b1db7a47034fb36a78a005ebff96290efb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>