QtForum.org

Hi Qt community-

I'm brand new to Qt. I've been doing a lot of research into QThread and the Signals & Slots mechanism, and am trying to put together the last piece of the following puzzle:

Let's say object A needs some work done. Object A queues its request into a standard semaphore'd/mutex'd request queue.

There is a thread pool of objects (QThread subclasses) hanging out, continually checking the queue for requests to process. Object B steps up to the plate.

My question is: what is the best method for object B to signal object A when it's done processing object A's request? We don't want a "permanent" connect() because it may not be object B that handles A's request -- it may be C, D, or E.

Since signals are inherently protected, object B cannot just call A->emit(workDone()), right? So that leads to object A having a public function that simply calls this->emit(workDone()). But that seems like a bit of a hack.

I hope my question is clear. Any help would be greatly appreciated.

Thanks.

--scope

yrenster-

Thanks for your reply. I think I understand your motivations for such a design, but why is that solution better than:

class A {
public:
void SignalWorkDone( void ) { emit WorkDone(); }
signals:
void WorkDone( void );
}


1) Thread B finishes object A's work
2) Thread B calls A->SignalWorkDone()
3) Thread A's slot to handle the signal is executed

With the design you proposed, object A would get a signal each time _any_ job is completed, not just those submitted by object A. Or I could be misunderstanding something.

Thanks again for your help.

--scope