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

[Thomas B. <Tho...@gm...>]

* Ethan A Merritt <sf...@us...> [2014-02-11 21:35]:
> On Sunday, 09 February, 2014 16:57:36 sfeam wrote:
> > > And indeed if I change the timeout:
> > > 
> > > --- a/src/qtterminal/qt_term.cpp
> > > +++ b/src/qtterminal/qt_term.cpp
> > > @@ -251,7 +252,7
> > > 
> > >         // The QLocalSocket::waitForConnected does not respect the
> > > time out argument when the
> > >         // gnuplot_qt application is not yet started. To wait for it,
> > > we need to implement the timeout ourselves
> > > -       QDateTime timeout = QDateTime::currentDateTime().addMSecs(1000);
> > > +       QDateTime timeout = QDateTime::currentDateTime().addMSecs(10000);
> > >         do
> > >         {
> > >                 qt->socket.connectToServer(server);
> > > 
> > > it suddenly almost starts working. I'm saying almost because the first
> > > plot doesn't work, but the second one does.
> > 
> > Hence my suspicion that timeouts < 1000msec are not working.
> > I suggest you do a global search and replace for timeouts and make
> > sure they are all >1000 msec.
> 
> I think I have uncovered part of the problem, but I do not understand
> why it is failing.
> 
> This loop:
>         do
>         {
>                 qt->socket.connectToServer(server);
>                 qt->socket.waitForConnected(200);
>                 // TODO: yield CPU ?
>         }
> 	while(...)
> 
> Does not work as intended.  
> 
> 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.

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