Удаление QtcpSocket без закрытия дескриптора(соединения)

[koldun90]

Возможно ли удалить объект QtcpSocket при этом не закрывать само соединение.
Суть в том что я передаю sockedescriptor
QAbstractSocket::socketDescriptor() и соответственно QAbstractSocket::setSocketDescriptor()
между потоками и  создаю в треде QtcpSocket.
Тред работает и затем в конце работы он должен освободить сам QtcpSocket, при этом как бы не разрывая соединение

[Racheengel]

В смысле, надо создать соединение в одном треде, а использовать в другом?

[ecspertiza]

По коду QTcpSocket не нашел что бы при деструкции он удалял физические сокеты. Нужно проверить. Думаю проверить можно достаточно просто. Поднять QTcpServer с одной стороны, с другой сокет, выполнить подключение, отправить данные и секунд через 5ть просто вызвать деструкцию сокета, далее посмотреть как себя поведет сервер.

[koldun90]

В смысле, надо создать соединение в одном треде, а использовать в другом?

совершенно верно
после использования в другом треде нужно удалить объект QTcpSocket(сделать deletelater) который был создан в другом треде(setsocketdescriptor), но соединение не закрывать

[Racheengel]

Насколько я понимаю, нет сокета - нет соединения.
Можно попробовать moveToThread вызвать, но ИМХО QTcpSocket - одна из самых косячных концепций в Qt...

[tux]

А может лучше архитектуру приложения пересмотреть?
Создавать соединение в одном потоке, а потом использовать его в другом - так себе идея. Хотя, если ТС любитель самобытных проблем...

[Авварон]

По коду QTcpSocket не нашел что бы при деструкции он удалял физические сокеты. Нужно проверить. Думаю проверить можно достаточно просто. Поднять QTcpServer с одной стороны, с другой сокет, выполнить подключение, отправить данные и секунд через 5ть просто вызвать деструкцию сокета, далее посмотреть как себя поведет сервер.

он действительно не закрывает сокеты потому что пришлось бы звать виртуальную функцию из деструктора

[koldun90]

Я использую сокт в таске (наследник qrunnable) передав туда socketdescriptor и создав там QtcpSocket и вызвав setsocketdeskriptor
когда я вызываю sock->write() данные у клиента не поступают, но когда делаю после вызова write   sock->waitforbyteswritte() данные приходят клиенту и он ловит у себя сигнал readyread.

ps с waitforbyteswritte() передается после этого думаю потому что если его не указывать то объект runnable уничтожается раньше наверно чем сокет реально передает в буфер ос

[koldun90]

получается я так понял что в наследнике qrunnable обязательно нужно использовать waitforbytewritten после write