do control return back returning to previous slot/function from where signal generate

[quickNitin]

hello everybody,
I have a place in code shown below where slot emits dataAvailable(). After that control will pass to corresponding slot. Do control returns back after execution of that slot.



void MyThread::run()
{



int fd0 = open("/home/prince/mydev01",O_RDWR|O_NONBLOCK);

while( ! _end )
{
read(fd0,&x,sizeof(int));
read(fd0,&y,sizeof(int));
emit dataAvailable();
_semaphore.acquire();
}
close(fd0);

emit stopThreadSignal();
cout<<"\tdataAvailable called";

}



In this case dataAvailable() leads to


void MyDialog::receiveOnRead()
{

QString sx;
sx.setNum(mth.x);
QString sy;
sy.setNum(mth.y);
label->setText(sx+QString(" ") +sy);
cout<<"From dialog thread"<<mth.x<<" "<<mth.y;
}


It just replaces the lable text.

Well i am sorry i keep asking such related questin again n again but ihave some doubts still prsisting. I have tried with some test pgms which donot make concept clear.

[wysota]

If Qt3 -- yes. In Qt4 -- it depends if a connection is direct (yes) or queued (no).

[quickNitin]

and in my case since signal connecting to a slot of object in different thread so it is queued. Is there any way to change this behaviour.
Or there any other way for acheieving what i want? I want control to go back to next instruction in run() after emission of signal. Is it possible in Qt?

[nupul]

I want control to go back to next instruction in run() after emission of signal. Is it possible in Qt?

well what you want is something similar to racing... a bad design problem. I would suggest that you try re-engineering the solution. Imagine the magnitude of the problem if what you were developing were a software for NASA!!

This is what i suggest, rest is upto you.

Nupul

[quickNitin]

i will try, but my question still exists. Can you suggest me anything.
One more question do event loop of thread starts by default or we have to use exec() as for queued connections.

[wysota]

I can only suggest that you use a wait condition to stop the emiting thread and release it from a slot. It's still a bad design though, because you may experience unwanted behaviour when two objects are connected to that signal.


QMutex m;
QWaitCondition wcond;
connect(thread, SIGNAL(someSignal()), someother, SLOT(someSlot()));
//...
void MyThread::someMethod(){
m.lock();
emit someSignal();
wcond.wait(&m);
m.unlock();
}
//...
void OtherClass::someSlot(){
doSomething();
wcond.wakeAll();
}

I don't know what will happen if the slot will be called immediately after emit someSignal(), before wcond.wait() -- you might end up in a deadlock. You might want to take a look at QWaitCondition docs to see how to avoid it.

[quickNitin]

i agreed to it as bad design approach . Any suggestion on any articles/papers where i can improve my knowledge

[wysota]

i agreed to it as bad design approach . Any suggestion on any articles/papers where i can improve my knowledge

Depends on what you want to achieve.

[quickNitin]

i will represent a analogy to my problem.
Ya ealier all those suggestions were not with me . I am integrating them .
For example say i have a plane ( i is getting much much exaggarated). Now at airtraffic control tower i have data (i think they have antenna ormay be through satellite ,don't know). I want to display that on map. Now there can be many planes also. I was thinking each thread will handle each such instance and report data availabitlity to gui thread.Currently as you had already answere it is bad design. I am looking for suggestion on such approach.

Well i donot have that fast data as fast location of plane and no such consistent availability also.

[wysota]

But why do you need one of the threads to wait for the other?

[quickNitin]

no i donot want thread to wait. only thing i want is simultaneous reading from fifo or socket and availability of newly read data in gui thread. I think i have been misunderstood here i want thread to wait.
Anyways on my uniprocessore machine one of the thread will wait when other is running.

[wysota]

Anyways on my uniprocessore machine one of the thread will wait when other is running.

But you won't know in what moment will it happen and this can lead to race conditions.

[quickNitin]

agreed to it.