MoveToThread (все-таки хочется понять ..)

[mutineer]

Разве тут не этот случай рассматривают?

Напугал старика.
А причем здесь очередь сообщений, если здесь соединение будет DirectConnect?

А причем тут тип коннекта? deleteLater() не удаляет же, а постит event удаления в eventLoop. А eventLoop уже закончился и до этого event'a не дойдет и объект не удалит

[Bepec]

Таки дык. То есть пришли к мнению, что поток с конструктором moveToThread ничего плохого не может сделать, если не считать из пальца выдуманных ситуаций и непродуманной архитектуры?

[BRE]

А причем тут тип коннекта? deleteLater() не удаляет же, а постит event удаления в eventLoop. А eventLoop уже закончился и до этого event'a не дойдет и объект не удалит

Точно-точно. Спешу.

[Странник]

Странник, ты же вумный - поясни в чём "плохость данного метода". И да, можно конкретики аля "делаем вот так, падает допустим через 4 часа".

просто потому, что такое решение создает проблемы на пустом месте и менее универсально. возникает два противоречивых требования: с одной стороны, объект QThread, живущий в потоке, хорошо бы уничтожить до завершения потока, но с другой стороны, прежде чем уничтожить QThread мы должны завершить работу потока, прервав цикл обработки событий через QThread::exit(). как правильно завершить работу потока и удалить объект QThread в этом случае? и вы начинаете ломать себе мозг, чтобы не наступить на грабли, которые сами же разложили.

[Igors]

Таки дык. То есть пришли к мнению, что поток с конструктором moveToThread ничего плохого не может сделать, если не считать из пальца выдуманных ситуаций и непродуманной архитектуры?

Да, вроде разобрались - само по себе moveToThread в конструкторе не есть баг (а то тыкают в нос линками ). Ладно, поехали по архитектуре?

Прошу показать пример/псевдокод где наследование от QThread явно плохо/неудачно.

просто потому, что такое решение создает проблемы на пустом месте и менее универсально. возникает два противоречивых требования: с одной стороны, объект QThread, живущий в потоке, хорошо бы уничтожить до завершения потока, но с другой стороны, прежде чем уничтожить QThread мы должны завершить работу потока, прервав цикл обработки событий через QThread::exit(). как правильно завершить работу потока и удалить объект QThread в этом случае? и вы начинаете ломать себе мозг, чтобы не наступить на грабли, которые сами же разложили.

Нет корректного способа убить нитку (и объект QThread) если она активна (не вышла из run). Наверное Вы имели ввиду что-то другое - тогда поясните

[Bepec]

Убивать нитки надо самому, а deleteLater() - просто более удобный инструмент, НЕПОДХОДЯЩИЙ в данной ситуации. И таких ситуаций я могу привести много Он далеко не универсален.

[V1KT0P]

Что то не лезет ко мне в голову пример при котором наследование от QThread и использовании moveToThread будет ронять сервер.
В моем понимании наследование от QThread является сродни использованию goto. И тем и тем можно спокойно обойтись, но в будущем может привести к ненужным костылям.

[Bepec]

Виктор а помоему вы чуть чуть суть не улавливаете

Плохого в этом ничего нет. Ни явного, ни скрытого. Точно так же любой виджет наследуется от QWidget.
Просто создаётся аналог(!) QWidget в другом потоке с необходимым нам набором функций.

Можно разбить его на 2/4/6/8/n+2 более простых элементов, но зачем?

[mutineer]

Да, вроде разобрались - само по себе moveToThread в конструкторе не есть баг (а то тыкают в нос линками ).

Так вопрос в использовании moveToThread в конструкторе или в использовании конструкций moveToThread(this) и thread->moveToThread(thread) ?

[Bepec]

Так вопрос в использовании moveToThread в конструкторе или в использовании конструкций moveToThread(this) и thread->moveToThread(thread) ?

Объясните мне разницу mutineer,пожалуйста, между

moveToThread(this)

и

thread->moveToThread(thread)
 

А так вопрос в использовании конструкции <потомок_QThread>.moveToThread(<потомок_QThread>);

Сам в себя, проще говоря.

[mutineer]

Так вопрос в использовании moveToThread в конструкторе или в использовании конструкций moveToThread(this) и thread->moveToThread(thread) ?

Объясните мне разницу mutineer,пожалуйста, между

moveToThread(this)

и

thread->moveToThread(thread)
 

А так вопрос в использовании конструкции <потомок_QThread>.moveToThread(<потомок_QThread>);

Сам в себя, проще говоря.

Разницы нет, кроме встреченного возгласа на форуме "а я не использую moveToThread(this), я делаю thread->moveToThread(thread)". Написал оба случая, чтобы не придирались подобным образом

[Авварон]

Да, вроде разобрались - само по себе moveToThread в конструкторе не есть баг (а то тыкают в нос линками ). Ладно, поехали по архитектуре?

Прошу показать пример/псевдокод где наследование от QThread явно плохо/неудачно.

Нет корректного способа убить нитку (и объект QThread) если она активна (не вышла из run). Наверное Вы имели ввиду что-то другое - тогда поясните

На самом деле, с архитектурной точки зрения - сабклассить тред - это использовать его не по назначению. Если у вас есть разовая операция над небольшими (большими?) данными - используйте конкаррент. Кутред (по идее) надо использовать, если есть асинхронная схема событие-обработчик.

[Bepec]

Я конечно боюсь вас прерывать... Но многое, если не всё, применяется совершенно неожиданно для разработчиков. Те же "ляпы" новичков, где строка является массивом, long boolем и прочая.
А конкурент... Я его ещё не изучал, ибо нужны были нитки - изучал нитки

[Авварон]

Я конечно боюсь вас прерывать... Но многое, если не всё, применяется совершенно неожиданно для разработчиков. Те же "ляпы" новичков, где строка является массивом, long boolем и прочая.
А конкурент... Я его ещё не изучал, ибо нужны были нитки - изучал нитки

Может быть вам был нужен конкурент как раз?

[Igors]

А второй вопрос "чистоты" архитектуры - тред задуман как КОНТЕЙНЕР для потока, место, где разрываются связи парент/чайлд и начинается полностью новый конктекст - ведь QObject не может иметь парентом объект в другом треде. И тред получается "мостом" между двумя иерархиями объектов - в родительском потоке и в дочернем. При этом сам тред принадежит родительскому потоку - тк именно он "должен" знать когда стартовать/стопать и удалять тред. И получается не очень логично - мы создаем и удаляем тред из родительского потока, а метод thread() с этим потоком не совпадает. Как-то так, извиняюсь за сумбурность:)

Мне кажется QThread просто (ну или по крайней мере в первую очередь) - это удобный класс для запуска ниток. Мы можем использовать его как контейнер или нет. Да, нитка стартует из другой (обычно главной) но зачем нам категорично утверждать ее "принадлежность"? Напр естественная/популярная схема:

- создал нитку и втулил moveToThread
- нитка создает свои объекты (в конструкторе или др местах) и удаляет их в деструкторе. Сигналы работают как надо (через eventLoop нитки)

Др словами нитка как бы "самодостаточна". Повторное использование - дождался завершения, удалил, создал снова - не проблема. Да, я "разорвал связи", да, я не говорю что это лучше чем "выносить воркера". Но чем это плохо? Где ужасные "костыли", "грабли" о которых так много говорится/пишется?