Currently, QThreadPool::waitForDone() (and by extension QFuture::waitForFinished()) may execute queued tasks directly in the caller thread, if all worker threads are busy. This is done to reduce the risk of deadlock, but in some scenarios it breaks assumptions about task affinity (e.g. tasks are expected to run only in worker threads, not the main thread).

There is no way to opt out of this behavior. Applications that require strict thread isolation cannot rely on QThreadPool as-is.

Steps to Reproduce:

1. Submit a long-running task to QThreadPool.

1. From the main thread, call QFuture::waitForFinished().

1. Observe that the task executes in the main thread (QThread::currentThread() == QCoreApplication::instance()->thread()).

Expected Result:
Tasks submitted to QThreadPool should only run in worker threads, unless explicitly configured otherwise.

Actual Result:
Tasks may run in the caller thread if it is waiting.

Proposed Fix:
Add a configurable option to QThreadPool to disable this behavior.

API proposal:
void QThreadPool::setAllowStealByCallerThread(bool enabled);
bool QThreadPool::allowStealByCallerThread() const;
Default is true (preserves current behavior). When set to false, waitForDone() will no longer execute tasks in the caller thread.

Rationale:
This gives developers stricter control over threading behavior and avoids surprising cases where the main/UI thread executes worker code.