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

[Bastian M. <bma...@we...>]

The workaround for a non-functional call to 
QLocalSocket.waitForBytesWritten in qt_flushOutBuffer seems to have a 
timing problem  - on Windows at least.

The sequence of flush and waitForBytesWritten(-1) dead locks and stalls 
gnuplot. This is easy to trigger when e.g. rotating 3d graphs rapidly 
with the mouse.

Just using waitForBytesWritten(-1) directly seems to work just fine, 
though. This is to be also indicated by a comment ("update: seems to 
work with Qt 4.5.") there. The patch attached is conditional on Qt >= 
4.5. Could somebody please test if that also works  on Linux/Mac?

   Bastian


Am 14.02.2014 06:52, schrieb Jérôme Lodewyck:
> I agree with Ethan that an event loop should not be necessary in qt_qterm.cpp.
> However, if someone wants to experiment, I have already made such an attempt
> to integrate a Qt event loop within the gnuplot event loop in
> http://sourceforge.net/p/gnuplot/patches/645/
> in eventloop.patch
>
> Jérôme
>
>
> Le mercredi 12 février 2014 20:14:19 sfeam a écrit :
>> I don't agree that an event loop is needed for this particular purpose.
>> We don't have a case of asynchronous processes sending each other
>> signals at random times.  We just want some way for the daughter
>> process to signal back to the parent process "I'm ready now, you can
>> proceed".   And we want some way for the parent to wait for this
>> signal without burning CPU cycles.   One would think from its name that
>> QLocalSocket::waitForConnected() provides exactly this service, but
>> evidently it doesn't.    At least in linux it should be possible to have the
>> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1). No
>> need to involve Qt in this.
>>
>> 	Ethan
>