Re: Reworked qt terminal is much faster – and fails to work on Mac

[sfeam <sf...@us...>]

On Tuesday, 11 February 2014 10:15:24 PM Thomas Bleher wrote:
> * Ethan A Merritt <sf...@us...> [2014-02-11 21:35]:
>
> > To see why, change it to this:
> > 	qDebug() << "qt_connectToServer " << server;
> >         do
> >         {
> >                 qt->socket.connectToServer(server);
> >                 if (!qt->socket.waitForConnected(TIMEOUT))
> >                         qDebug() << qt->socket.errorString();
> >         	usleep(50000);
> > 	}
> >         while(...)
> > 
> > Regardless of the value of TIMEOUT, including -1 or blank,  the
> > waitForConnected returns immediately with an error:
> >          "QLocalSocket::connectToServer: Invalid name" 
> 
> [Note: I haven't looked at this in detail, so these are just my guesses]
> 
> I think the error is probably a race condition:
> - gnuplot starts the external gnuplot_qt process
> - Immediately afterwards it tries to connect to the socket from
>   gnuplot_qt
> - Depending on scheduling, gnuplot_qt may have had a chance to run or
>   not. But in any case it needs to do some initialization first.
> 
> So my guess is that the "Invalid name" error stems from the fact that
> during the first iteration of the loop, the named pipe (which is created
> by gnuplot_qt) is simply not there yet.

That makes sense, but the first attempt to connect _always_ fails,
even if I explicitly wait for several seconds before invoking waitForConnected().
So I think it's not just a timing race.  There's something that doesn't
get initialized until the first connection attempt. So the first attempt fails
but then the next attempt succeeds.

I have gone ahead and placed a variant of that modification into CVS.
I think the worst it can do is hang a session that was going to fail anyhow.
We can still fix the source of the initial failure if we ever find it.

> I also looked through the recent changes to the gnuplot code just now,
> and noticed that no QApplication object is created anymore in gnuplot.
> According to the docs, waitForConnected() should also work without an
> event loop, but I think it would still be interesting to see if the high
> CPU usage goes away if QCoreApplication is replaced by QApplication.
> Just my 2cents.
> Thomas

I don't see any difference here, but then I wasn't seeing CPU-churning
to begin with.  Let's see what the Windows/OSX people report.

	Ethan


>   
> > Without the usleep() it spews hundreds or even thousands of these errors
> > before fallling through to the rest of the code.  The usleep reduces this
> > to a manageable number of error reports. 
> > So the first connection attempts always fail, even under linux, and the
> > failure is immediate.
> > Why is it an invalid name?  I don't know.
> > How does it eventually succeed?  I don't know that either.
> > 
> > Since TIMEOUT is ignored this is becomes a CPU-burning loop,
> > which is what Mojca originally reported.  The usleep should fix that, and a 
> > large enough manual timeout as in  
> >      QDateTime timeout = QDateTime::currentDateTime().addMSecs(30000);
> > may in fact be necessary.  But it would be nice to understand the real
> > reason why the initial connection attempts fail, because maybe we can
> > test and wait on that condition directly and avoid the useless loop here.
> > 
> > 	Ethan