QThread генерирует ошибку до начала выполнения

[Dendy]

Принадлежность к потоку обьектов вообще и сокета в частности определяется тем, в что этом потоке будут дёргаться виртуальный метод QObject::event(). Создавайте сокет внутри своего run() - это сделает его принадлежащим потоку, которому этот run() принадлежит.

[foxexe]

ну да значит я всё правильно думаю, спасибо огромное

смотря на тему становится даже немного стыдно)

[Dendy]

Да ладно, работа с потоками - то ещё болото. И никакая теория не будет полноценной, пока сам в нём не искупаешься.

[BlackTass]

можно создавать и в конструкторе, главное только потом перенести с помощью метода moveToThread() (метод класса QObject). Вызывать его надо из того потока, где был создан объект. И не забудьте объект самого потока перенести в этот поток.

[Dendy]

И не забудьте объект самого потока перенести в этот поток.

Сильно сомнительный подход, от которого больше проблем. Лучше так не делать. Как минимум события потока, а следовательно и слоты, не будут обрабатываться до и после exec().

[foxexe]

Да ладно, работа с потоками - то ещё болото. И никакая теория не будет полноценной, пока сам в нём не искупаешься.

да это я абсолютно согласен. Мне хватило даже институтских прог сначала винда, потом соляра, и там эти вещи побезопасней для потоков сделаны вроде.

можно создавать и в конструкторе, главное только потом перенести с помощью метода moveToThread() (метод класса QObject). Вызывать его надо из того потока, где был создан объект. И не забудьте объект самого потока перенести в этот поток.

очень хорошо подмечено, я и забыл про moveToThread(). однако это не решает моей архитектурной проблемы обработки приёма и отправки в разных потоках. ладно буду думать что тут делать.
А зачем мне переносить объект потока к себе в поток?

[BlackTass]

Сильно сомнительный подход, от которого больше проблем. Лучше так не делать. Как минимум события потока, а следовательно и слоты, не будут обрабатываться до и после exec().

ну после exec() в большинстве случаев наступает смерть потока.

Зато такой подход позволяет отделить обработку слотов объекта потока от потока-родителя (примерно в половине случаев это гуй-поток), что соответственно разгружает его.

Хотя вы правы, я погорячился советовать это делать всегда. Нужно понимать к чему приведет такое и для чего это нужно.

[Dendy]

А зачем мне переносить объект потока к себе в поток?

Как правило в run() создаётся нечто, что будет там жить и ловить события. Поток засовывают сам в себя когда лень создавать новый класс-обработчик, наследник QObject. Однако такой подход рвёт всё управление событиями/слотами экземпляром потока извне и влечёт ошибки на пустом месте. Технически никакого преимущества, кроме того, что два класса смешаны в один. И да, фильтр событий тоже не будет работать между потоками, зачем так сделано в Qt мне непонять.

[BlackTass]

Однако такой подход рвёт всё управление событиями/слотами экземпляром потока извне и влечёт ошибки на пустом месте. Технически никакого преимущества, кроме того, что два класса смешаны в один.

Ну по сути да, удобство только в исключении класса. Ну и в отстутствии пробросов сигнал-сигнал-слот для необходимых снаружи слотов, которые должны испольняться в отдельном евентлупе