问题
When a QTcpSocket
(or QSslSocket
) is upgraded to a QWebSocket
, the former has to be stored for the future purpose, as it requires to be ...
- moved to the same thread wherever
QWebSocket
is beingmoveToThread()
deleteLater()
wheneverQWebSocket
is being destroyed
Failing to do 1. results in undefined behaviour and most likely a crash. While failing to do 2. results in a memory leak, which is more prominent if you are having a QWebSocketServer
(QWebSocketServer - not releasing memory).
I learned these hard way, as it's not well documented. :-)
Recently did code refactoring for our QWebSocketServer
architecture. Due to that, I am seeing a strange behavior. --> Whenever there is an error from the remote client, i.e. QWebSocket::error()
signal, the underlying QTcpSocket
is emitted with destroy()
signal by something external and is possibly deleted.
There might be some coding mismatch possibility, which causes this scenario, but IMO it's less likely. So without going into the code details, I wanted to ask...
Question: In the context of QWebSocket
, is the underlying QTcpSocket
destroyed by the Qt framework in certain scenario?
回答1:
Upon web socket error or disconnection, the underlying socket is destroyed by Qt framework.
Since Qt manages the memory of underlying QTcpSocket
, the assumption in 2. is wrong.
I found out there to be a coding error, where I was not effectively performing deleteLater()
in earlier code. Which gave me an impression that we have to manage the underlying QTcpSocket
.
来源:https://stackoverflow.com/questions/58870100/is-the-qtcpsocket-or-qsslsocket-which-underlies-a-qwebsocket-destroyed-by-i