Russian Qt Forum

В слоте нужно узнать адрес объекта, который испустил сигнал. Можно конечно в параметрах сигнала передавать адрес. А можно ещё как-нибудь? Вроде в Qt для этого есть какие-то методы?

sender() - прям и не догадаешься...

QObject::sender()

старая песня о главном))) в общем случае - вы и не должны знать. никак и никогда.
про QObject::sender()- как помню, ассистант рассказывает следующее: данный метод противоречит философии сигнал-слотов и работает только внутри одного потока. Если сигнал из другого потока - то метод возвращает "ничего" (оно и понятно - к моменту получения сигнала объект-источник давно уже мог быть уничтожен)

Более того - понимаю так, что из этого следует и то, что работать оно не будет и в одном потоке если метод вызова слота - "квотед коннекшн".
Возможно и при некоторых других типах соединений - тоже (в 4.5 ввели  новые типы соединений - потому и не знаю).

В общем, имхо, ссылка на объект-источник типа QPointer передаваемая с сигналом - это получше будет и поуниверсальнее, хотя и "более тяжелая конструкция". но QPointer::isNull() удобен.

Замечательное и полезное пояснение, но топикстартер не указал нюансы, которых судя по вопросу и нет. Поэтому кратко: каков вопрос - таков ответ. А в дефолтных условиях однопоточности и дефолтном же состоянии соединения сигнала со слотом - работать будет.

Спасибо за разъяснение. В моём случае как раз сигнал из др. потока.

неверно, при типе DirectConnection всё ок ;)

Из другого птока можно только QueuedConnection... всё остальное черевато большими проблеммами...

QBlockedQueuedConnection гарантирует что отправитель жив (он ждет ответа). Ну конечно если устроит по скорости

не чревато, у меня рабочий проект, веб-серфер работает как раз по такому принципу: второстепенные потоки шлют сигналы на главный гуишный поток (с целью создания qwebview), тип сигнала directconnection. Потоков доходило одновременно до 400, проблем никаких никогда не возникало.

у меня тоже на linux'e нормально работало, но при переносе  на винду всё полетело. По сигналу из дочернего потока нужно было сделать ресайз окна... так вот это и падало. Да и прогрес бар не обновлялся.
Дело в том, что при директ коннекшине код ГУИ потока будет исполняться в дочернем потоке, что само по себе опасно. Некоторые системы, например, иксы это могут переваривать, а некоторые - нет. (мог ошибиться в своих выводах)
То что у вас не возникало проблем - ИМХО чистая удача...
ЗЫ: сейчас попробую набросать пример.

А вот и пример(в аттаче)
Оказывается наврал... на линуксе тоже падает, зато хорошо показыват что так делать нельзя.

Почитал асистент ещё раз про директКонекшн.
Ни слово про то, что слот будет выполнятся в потоке излучателя сигнала.

juvf, не там читали:

Видимо зависит от линукса и от версии кьют. У меня не падает, но при директе гадит:
что вполне естественно. :)

Сорри, спутал, у меня directconnection был когда проект писался на Qt Jambi. В сишном варианте сейчас посмотрел - QueuedConnection, работает одинаково в винде и линуксе.

под дебагом запускал, поэтому на ругань не обратил внимания...  в аттаче попровленный пример...
Вот что странно... если сначала запустить с QueuedConnection, а потом с директ, то всё работает (и плюётся сообщениями даже если не указывать предка в конструкторе), а если сразу с директ то рушится... почему - не понятно(почему работает... идеи?)...

бывает...  ;)

для межпоточных взаимодействий QPointer кривой by disign.  isNull() не атомарен и не гарантирует ничего на следующем же такте процессора. Его можно использовать только в одном потоке. Подробнее об этом написано в доках.

Для межпоточных вещей есть пара из указателей QSharedPointer и QWeakPointer - если конечно хотите обойтись без мютексов и т.п.

о как! секнкс) не дочитал, ассистант громаден как БСЭ)

Что-то всё как-то сложно..... QPointer...... который не работает....... потом пара из указателей QSharedPointer и QWeakPointer.......

я сделал просто, в лоб
Может такое решение тоже таит подводные камни?

ps
У меня тоже есть такое сообщение. Стал разбираться - действительно, парент создан в ГУИ потоке, а во 2-ом потоке создаю объект и пытаюсь указать родителя, созданного в ГУИ потоке. На работу приложения это не влияет. Приложение работает так, как надо. Поэтому пока на это забил.  Но это сообщение напрягает. По хорошему, надобы разобраться....

QPointer работает, но для одного потока, т.е. isNull() не гарантирует что объект не будет удалён в другом потоке. В более ранних версиях Qt была аналогичная функция у  QMutex, сейчас она закомменчена в коде, поскольку не имеет смысла, файл qmutex.cpp:

Вам нужна блокировка самого объекта, QSharedPointer как раз и позволяет это. В примерах достаточно хорошо всё описано, достаточно один раз разобраться. Единственное, до Qt 4.6 не хватало пары функций для удобного их использования (помоему какого-то конструктора и operator=) - а начиная с 4.6 всё хорошо.


Будет работать, конечно, если вы уверены что указатель на объект будет валиден все время пока принимаются сигналы. Другое дело, что решение такое несколько хрупкое - через какое-то время можно забыть тонкости реализации, и тогда бац, будем валиться - хорошо если постоянно, плохо если эпизодически в самый неподходящий момент.


объекту создаваемому во 2-м потоке укажите парента = 0. Qt не может удалять дочерний объект живущий в другом потоке и ставит parent=0 за вас - о чем и предупреждение. Удаляйте его сами при завершении потока, но не забывайте - указатель на этот объект, возможно, кому-то нужен - ведь я так понял, его вы передаёте вместе с сигналом в main thread.

если что, вот примерная реализация для shared-weak pointers


пояснения к примеру:
-указатель на объект не должен храниться где-то ещё, кроме shared-weak указателей - иначе сам объект можно будет удалить через delete ... и никто об этом не узнает.
-SharedPointer - содержит атомарный счётчик объектов, при достижении счётчиком нуля объект будет удалён автоматически.
-QWeakPointer - слабая ссылка, по сути это указатель на SharedPointer с атомарными операциями. Сам по себе никогда не задерживает удаление объекта и нужен лишь для получения строгого указателя.
-можно обойтись без QWeakPointer если логика несложна и нет риска хитрым алгоритмом задержать объекты в памяти (вызвать тем самым утечку)
-ну и да, независимо от реализации никто не гарантирует корректность межпоточных операций для данных того объекта, к которому вы обращаетесь из разных потоков (то есть гарантируется только валидность указателя).

Сложновато для понимания и для поддержки. Напр. могут возникнуть казусы если mySignal передает аргумент по ссылке. Есть смысл действовать проще, создав четкие правила кто отвечает за создание и кто за удаление, напр так

C++ (Qt)
// посылающий
emit mySignal(new ClientData(arg1, arg2, &mData));  //  отвечает за создание 
 
// получатель
void mySlor( ClientData * src )
{
//.. обработка
 delete src;       // отвечает за удаление
} 
 

При этом деструктор ClientData может и не удалять какие-то члены - их удаление возьмет на себя отправитель

Тут понятно, а тут нет....

Ну во первых про то что излучателя может уже не быть не подумал. Но сейчас подумал и в принцепе таких мест нет. излучатель всегда будет жыть. Хотя теоретически в будущем может и не быть. Буду делать защиту.

2maxxant
Во вторых, не понял я вашего примера..... Вот как я сделал

теперь ваш пример. Требуется в слоте узнать излучателя сигнала. На сколько я понял ваш пример, то с сигналом передается указатель на какой-то объект, созданные во втором потоке, а не указатель на излучателя. может имелось ввиду так ран делать?

ну может и не заморачиваться действительно - а там в будущем, возможно, найдётся решение получше. Заговорили про QPointer и т.д., я показал примерчик, но про this уже и забыл. Если this засунуть в QSharedPointer, то при удалении последнего указателя уничтожиться и сам объект, что весьма вероятно произойдёт в run(), так лучше не делать конечно ))

Ну и вообще если планируется QueuedConnection, то лучше run не трогать (не перекрывать). Непрактично - по умолчанию run вызывает exec и нитка может принимать сигналы. А перекрыли - придется проверять eventLoop самому

Никто же не запрещает в перекрытом run самому вызвать exec.

Конечно - но ведь он управление не отдаст. Не смертельно - но неудобно/непрактично

C++ (Qt)
void Thread::run()
{
	QEventLoop loop;
	for(;;)
	{
		...
		loop.processEvents();
		...
	}
}
 

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

Ээээ. Не очень понял о чем речь.
Что за "утомительный код", что может случиться в processEvents, и что мешает работать сигналами с двух сторон?

Ничто не мешает. Но если вся обработка в processEvents (при получении сигналов/событий) зачем тогда попусту перекрывать что делает run сам? Конечно имеет смысл если есть резоны для спец-обработки (остановить цикл или войти в специальный) - но они должны быть (редко).

Igors, ты описал проблему:

Я написал как это можно обойти.  :)

"Редко-часто" это относительные понятия и очень субъективные.  ;)

Что значит "перекрыть run"?