Вопрос про слоты в потоке.

[lit-uriy]

>>А что в данном случае перемещает moveToThread? Я так понимаю если его вызвать из Worker'a как раз самого Worker'a он и переместит. Нет?

Я полагаю, что некий объект живёт только в том потоке, в котором он был создан.
т.е вызвав moveToThread для некого объекта, он всё же не переедет жить в другой поток, но объекты создаваемые внутри "мовнутого" и только после того как его "мовнули" буду созданны уже в отдельном потоке.

П.С. в технических подробностях не шарю.

[ssoft]

Ваш перепредыдущий комментарий неверен
Если отнаследоваться от QThread и в конструкторе сделать moveToThread(this), то мы получаем класс, который полностью существует в своём потоке. И никаких дополнительных телодвижений не надо

Наследование от QThread и вызов в конструкторе moveToThread(this) дает, конечно, необходимый результат, и при быстром решении конкретной задачи может быть использован.
Я предложил решение, рассматривая задачу в общем виде (я же не знаю заранее, как будет использован Worker).
В случае же наследования и использования moveToThread(this) существуют ограничения, о которых необходимо помнить

Нельзя указывать родителя, иначе moveToThread не сработает.

The object cannot be moved if it has a parent.

Если объект без родителя создан в куче (через new), а не на стеке, то необходимо использовать соединение с deleteLater, что иногда является настоящим геморроем.
Если объект создан на стеке, то его принудительное удаление может быть вызвано в момент его работы в другом потоке, что приведет к crash.

Все эти нюансы могут быть неочевидны программистам с малым опытом работы с Qt, его QObject и QThread.

[Igors]

А что в данном случае перемещает moveToThread? Я так понимаю если его вызвать из Worker'a как раз самого Worker'a он и переместит. Нет?

У QObject есть поле/метод thread(), оно используется для определения в каком EventLoop он принимает сигналы. Никакого "перемещения" не происходит. Как работает QueuedConnection:

- по thread получателя находит его EventLoop и кладет туда сигнал (событие)
- когда поток освободится он полезет в этот EventLoop и извлечет оттуда событие (просто сработает слот приемника)

Нужно реализовать загрузчик прошивки по последовательному порту.
Процесс примерно такой:
1. Выбор файла прошивки .hex, парсинг проверка прошивки, если ок, то активировать кнопку загрузки.
2. Ожидание нажатия кнопки загрузки пользователем.
...
Ожидания реализованы с использованием QWaitCondition::wait(). ..

Зачем связываться с низкоуровневой синхронизацией? Просто лупите слот/сигналами, и все дела. Запустили нитку, она вошла в run - exec, стоит, ждет событий. Нажал юзер бубочку - послали сигнал, нитка его подхватила. Если она была чем-то занята - подхват случится после завершения этих занятий.

Взаимный обмен/ожидания - тоже проще всего слот/сигналами. Что конкретно не выходит, чего не хватает (зачем лепите свой loop и wake)?

Да, по QWaitCondition Верес у нас большой специалист  

[Bepec]

Ssoft пишет правильно, но чуть чуть неверно
Все описанные им проблемы - невнимательность программиста и непродуманность архитектуры. Они в любом случае помешают проекту.