multithreading - Qt/C++ how to wait a slot when signal emitted -

i have developed app in qt/c++, have used signal/slot mechanism interact between 2 threads. first thread run ui/treewidget , second 1 run framework

i got issue on 1 action.

in ui side, before starting action, i'm connect signal/slot between ui , framework such below in treewidget.cpp

connect(&m_framework, &framework::requestifnameexist, this, &treewidget::requestifnameexist); connect(this, &treewidget::sendanswerifnameexist, &m_framework, &framework::notififnameexist); 

the framework, start , send requestifnameexist:

emit requestifnameexist(tmpname, item, fileinfo.isdir());  while(waitingresponse == false){     usleep(200); } 

i have added loop because need wait feedback. strange things in treewidget.cpp, never enter in

void treewidget::requestifnameexist(qstring name, treewidgetitem *parent, bool isfolder) { #ifdef puls_log     qlog_info() << "[treewidget] [requestifnameexist] "; #endif     emit sendanswerifnameexist(isnameexist(name, parent), isfolder); } 

i never access requestifnameexist in treewidget signal emitted.

i have put while loop in framework wait feedback treewidget

void framework::notififnameexist(qtreewidgetitem *item, bool isfolder){      if(item != null)         item->isfolder = isfolder;      waitingresponse = true;  } 

any idea why signal emitted framework never arrived on treewidget ? coming while ??

is there way not use while such "wait event" + timeout

thanks

my first thought having either thread block until operation in other thread completes poor design -- partially defeats purpose of having multiple threads, allow multiple operations run in parallel. it's liable result in deadlocks if you're not careful (e.g. if both threads decide emit-and-wait @ approximately same time!)

a better design have initiating method emit requestifnameexit , return immediately, initiating thread's event loop can continue running usual during operation. then, when other thread has done work, responds emitting own response-signal, causing appropriate/connected slot-method in first thread called, @ point results handled in first thread.

that said, if insist on wanting block execution of signal-emitting thread inside method, until other thread has finished executing associated slot-method, can behavior setting signal/slot connection's type qt::blockingqueuedconnection (the connection type can specified via optional argument connect()). if that, emit call won't return until slot-method (in other thread) has finished executing. given that, can results other thread passing pointer data object 1 of arguments in signal/slot method signature, , having other thread populate data object necessary. when emit returns can examine contents of data object see results.