[Qt-interest] A bug? Busy looping in QAbstractSocket triggered by full read buffer

[Brendon Higgins]

Thiago Macieira wrote (2010-12-11 21:24):
> On Saturday, 11 de December de 2010 09:29:25 Brendon Higgins wrote:
> > In qabstractsocket.cpp, lines 1832--1859 are a "forever" loop, where the
> 
> Please include the Qt version number or SHA-1 of the commit you're looking
> at when you mention line numbers.

Apologies, I completely forgot to mention a version. I'm using 4.6.3, but I 
also had a look at the 4.7.1 source which appeared to be the same.

> Lines 1832 through through 1836 for me are the comments just before the
> QAbstractSocket::waitForReadyRead function starts (which is line 1837).
> There's a "forever" on line 1862 for me and one on 1920, so I'll assume you
> meant the first one...
>
> > code apparently busily waits for data to arrive ready to read. Notice
> > lines 1849--1852. Let's assume readyToRead is true (also assume the
> > socket
> 
> I guess you mean these lines:
> 
>   1879          if (readyToRead) {
>   1880              if (d->canReadNotification())
>   1881                  return true;
>   1882          }

That's right.

> It sounds like an unforeseen condition. If the buffer is full,
> QAbstractSocket cannot read more data. But that also means it can't emit
> waitForReadyRead, because it hasn't read more data.
> 
> So it sounds like it should return under those conditions with a new error
> code.
> 
> At the same time, the caller should avoid calling waitForReadyRead if the
> buffer is already full. It's asking for an impossible condition. If the
> timeout is not -1, we might code the function so that it simply sleeps for
> the timeout period.

Okay. Would it be helpful if I sign up to the bug tracker and file a report, 
then?

I suppose I should also file a report to khttp about it asking for impossible 
conditions.

Thanks for your help,
Brendon