How to send a unique copy of a signal to several separate objects?

[Lesiok]

Do not use signals only QMetaObject::invokeMethod.

[yeye_olive]

Lesiok's solution clearly is the way to go with your current infrastructure.

However, allocating a QThread for each worker is expensive. Do you really need the workers to run in separate (and persistent) threads, or do you only need them to run outside the main (GUI?) thread, in as many threads as the system can effectively run concurrently? In the latter case, consider using QtConcurrent::run().

[nthexwn]

Do not use signals only QMetaObject::invokeMethod.

So if I'm understanding this correctly, I want something like this instead?

void makeASpecificWorkerDoSomething(int indexOfSpecificWorker)
{
    // Look up worker
    Worker* specificWorker = workersAndThreads[indexOfSpecificWorker].first;
 
    // Schedule worker to do something in its own event loop
    QMetaObject::invokeMethod(worker, SLOT(doSomething()), Qt::QueuedConnection);
}

void makeASpecificWorkerDoSomething(int indexOfSpecificWorker)
{
    // Look up worker
    Worker* specificWorker = workersAndThreads[indexOfSpecificWorker].first;

    // Schedule worker to do something in its own event loop
    QMetaObject::invokeMethod(worker, SLOT(doSomething()), Qt::QueuedConnection);
}

To copy to clipboard, switch view to plain text mode 

Do you really need the workers to run in separate (and persistent) threads, or do you only need them to run outside the main (GUI?) thread, in as many threads as the system can effectively run concurrently? In the latter case, consider using QtConcurrent::run().

I believe I do need them to run in their own persistent threads. Each thread is running a separate copy of a game. Each game uses the event loop on that thread to interface with an AI (or player) either directly (compiled into the program) or through the network. As far as I can tell QtConcurrent just launches a single function per thread and doesn't provide event loops. Is that correct?

I suppose I could re-write the game to use its own manually written loop inside a main function instead of relying on the event loop provided by QThread. Do you believe this would be a better approach?

[yeye_olive]

So if I'm understanding this correctly, I want something like this instead?

void makeASpecificWorkerDoSomething(int indexOfSpecificWorker)
{
    // Look up worker
    Worker* specificWorker = workersAndThreads[indexOfSpecificWorker].first;
 
    // Schedule worker to do something in its own event loop
    QMetaObject::invokeMethod(worker, SLOT(doSomething()), Qt::QueuedConnection);
}

void makeASpecificWorkerDoSomething(int indexOfSpecificWorker)
{
    // Look up worker
    Worker* specificWorker = workersAndThreads[indexOfSpecificWorker].first;

    // Schedule worker to do something in its own event loop
    QMetaObject::invokeMethod(worker, SLOT(doSomething()), Qt::QueuedConnection);
}

To copy to clipboard, switch view to plain text mode 

Almost. As the documentation for QMetaObject::invokeMethod() specifies: You only need to pass the name of the signal or slot to this function, not the entire signature. Which yields:

QMetaObject::invokeMethod(worker, "doSomething", Qt::QueuedConnection);

QMetaObject::invokeMethod(worker, "doSomething", Qt::QueuedConnection);

To copy to clipboard, switch view to plain text mode 

Notice that you could omit the argument Qt::QueuedConnection, because doing so uses the default Qt::AutoConnection, which behaves like Qt::QueuedConnection in this case (worker does not live in the thread executing QMetaObject::invokeMethod()).

I believe I do need them to run in their own persistent threads. Each thread is running a separate copy of a game. Each game uses the event loop on that thread to interface with an AI (or player) either directly (compiled into the program) or through the network. As far as I can tell QtConcurrent just launches a single function per thread and doesn't provide event loops. Is that correct?

That is correct, QtConcurrent::run() only schedules a function to be run in another thread taken from a thread pool once one becomes available. Since you need event loops, your current solution looks reasonable. If, during the optimization phase of your project, you realize that too many threads remain idle often enough, then you could try to run several instances of the game in each thread.

I suppose I could re-write the game to use its own manually written loop inside a main function instead of relying on the event loop provided by QThread. Do you believe this would be a better approach?

Probably not, unless performance becomes an issue and you can measurably improve it by tailoring the event loop to your needs. Your current approach seems well adapted to your use case at this stage.