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

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

On 02/12/2014 03:24 AM, Yuriy Kaminskiy wrote:
> Daniel J Sebald wrote:

>> Looking at the debugger results below, it seems that qt_term.cpp is
>> having problems at or near lines 423-424:
>>
>>> 748,772,...  [0x1001da24c,0x1001da264,...]  qt_term.cpp:424
>>>       +                       118 qt_sendFont()  (in gnuplot) +
>>> 737,713,...  [0x1001da241,0x1001da229,...]  qt_term.cpp:423
>>>       +                       110
>>
>> and the code hunk around there is:
>>
>> while (!receivedFontPropos)
>> {
>>     qt->socket.waitForReadyRead(1000);
>> 423  while (qt->socket.bytesAvailable()>= (int)sizeof(gp_event_t))
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Not sure, but this looks very wrong. If this condition ever triggers (there are
> less than sizeof(...) bytes in socket), it will result in infinite busy-loop (if
> there are *any* bytes in socket, waitForReadyRead will instantly return,
> receivedFontProps is not changed, bytesAvailable check will fail again, etc).
>
> I think same apply to similar code in qt_waitforinput().
>
> (However, it is unlikely to be related to discussed bug (I expect it can only
> trigger on gnuplot and gnuplot_qt version/ABI/architecture mismatch). Still, it
> feels a way too fragile; IMO, there should be at very least mutual validation of
> sizeof(gp_event_t) at startup).

I agree.  In previous posts I didn't put much thought into "good" fixes 
for these loops because, as you say, it seems too fragile.  If I have 
time this weekend I'll see if I can put something together using 
signals/slots.  It shouldn't be difficult.

Dan