Qt terminal speedup by placing socket within separate thread?

[Daniel J S. <dan...@ie...>]

OK, here's a follow-up post on what I've learned from reworking the 
waiting constructs of the qt_term.cpp file.

Oh, first I forgot to say in the previous post that the patch did not 
address the issue of Qt terminal dimensions persistence.  We can do that 
after patch #653 is stable.  Basically, gnuplot_qt needs a command that 
will send back position information just as it does with the font 
information.  Should be easy once things are stable.

After patch #653 is stable, I'd like to revisit the idea of using a 
separate thread to, in this case, improve the efficiency of data 
transfer.  Here is what I think is the biggest ramification of not 
having an event loop to work in.  The stream of data intended for 
gnuplot_qt is first sent into an intermediate output buffer and then 
later written to the server socket with a continual flush.  That is 
repetitive and, I think, can be avoided with an event loop in a second 
thread.

This routine is the core of the issue:

void qt_flushOutBuffer()
{
	if (!qt || !qt->socket.isValid())
		return;

	// Write the block size at the beginning of the block
	QDataStream sizeStream(&qt->socket);
	sizeStream << (quint32)(qt->outBuffer.size());
	// Write the block to the QLocalSocket
	qt->socket.write(qt->outBuffer);
	// Reset the buffer
	qt->out.device()->seek(0);
	qt->outBuffer.clear();

	while (qt->socket.bytesToWrite() > 0)
	{
		// Write as much data at once as the operating system will allow
		// for the socket.
		qt->socket.flush();

#if 0  // 2014mar02 NOT SURE THIS IS NEEDED
		// Avoid dead-locking when no more data is available
		if (qt->socket.bytesToWrite() > 0)
		{
			if (!(qt->socket.waitForBytesWritten(DEFAULT_TIMEOUT)))
			{
				qDebug() << "qt_flushOutBuffer: Bytes not being written to socket";
				qDebug() << "qt_flushOutBuffer:" << qt->socket.errorString();
				break;
			}
		}
#endif
	}
}


Because there is no event loop, the use of "socket.flush()" is 
mandatory.  If the socket were in a separate thread with an event loop, 
all that would be needed is a write to that socket.  The even loop would 
then manage data flow out to the peripheral gnuplot_qt.  See this reference:

http://qt-project.org/doc/qt-4.8/qlocalsocket.html#flush

    "In most cases, you do not need to call this function, because 
QLocalSocket will start sending data automatically once control goes 
back to the event loop. In the absence of an event loop, call 
waitForBytesWritten() instead."

So, what I'm wondering is if we start a thread and then move the socket 
over to that thread that might obviate the need for flushing anywhere. 
If that is the case, then perhaps instead of sending all the terminal 
API commands to an intermediate qt->outBuffer.  If that is the case, it 
might make qt_term/gnuplot_qt data transfer a little faster.

Do you think that will improve things Jérôme?  Maybe next weekend I'll 
give that a try if it makes sense.

Dan