[Interest] QLocalSocket bug?

Igor Mironchik igor.mironchik at gmail.com
Tue Jan 5 18:30:30 CET 2016



On 05.01.2016 20:18, Jason H wrote:
>> Hi,
>>   I am adapting existing code from QTcpSocket to QLocalSocket (The TCP code was used for distributing computations over a network, but since I also want to separate the local computation in a sub-process, I'm using the TCP > code for IPC using QLocalSocket).
>>   On the server side, the readyRead() signal is connected to an incomingData() slot which processes data using a loop:
>>   while(socket->canReadLine())
>> {    command = socket->readLine();    processCommand(command);
>>
>> }
>>   
>> Now, when the connection gets closed, I am receiving a readyRead() signal after the socket is closed (this is confirmed by socket->isReadable() which is false)
>>   
>> But still, socket->canReadLine() returns true, and socket->readLine() returns an empty string, which leads to an infinite loop.
>>   
>> I can fix this by adding socket->isReadable() in the loop condition, but I am wondering if this is a QLocalSocket bug that should be filed.
>>   
>> Also, why is QLocalSocket not inheriting QAbstractSocket? They share a very similar interface, this would make things easier when developing somethinh which would use seamlessly network sockets and local pipes.
>   
> When this happens it is usually the result of queued vs direct signal/slot connections. If using direct, you are going deep in the stack, if queued, the execution order is not guaranteed. You should leave the guards in.

He asked why canReadLine() always returns true when readLine() invokes 
in the loop, so the loop is infinite... Execution order doesn't explain it.

>
> As for the QAbstractSocket, I agree with you. The current QAbstractSocket should really be called QIpSocket, deriving from a more general QAbstractSocket. I think the concept when it was programmed is local sockets are implemented very differently internally and therefore can behave very differently, lack of or larger a MTU, there also is no host to connect to. So I think it was a big enough concept split that ended us up in this situation.
>
> By the way, I've found quite a few timing bugs in application code when moving to a local socket. I got much bigger packets.
>
>   
>   
>   
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest




More information about the Interest mailing list