QEventLoop and QThreadPool Shutdown Problems

I'm doing tabbed searching of the local machine where each tab has its own search running. The main thread object owns a QThreadPool and sends a thread to each new tab object it creates. Each tab object has a QEventLoop. The tab object's run() function instantiates the QEventLoop on the heap and then calls exec(). Problems occur at app shutdown (with open tabs) when the main thread calls QEventLoop::quit() on the running loops:

ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread 94b5660. Receiver 'TabResults' (of type 'QWidget') was created in thread 37be0", file kernel\qcoreapplication.cpp, line 305

and immediately thereafter when the main thread deletes all the open tabs:

QObject::killTimers: timers cannot be stopped from another thread

I've tried most combintions of also placing the quit() and delete calls in the actual tab object's destructor or in a tab object slot, in convolution with, oddly, placing the quit() call AFTER the destructor call, as in:

delete pTab[i]; // main thread deleting one of the active tab object pointers' data structures
pTab[i]->quitLoop(); // main thread calling active tab object wrapper for QEventLoop::quit()

which typically results in no assert failures or errors but leaves dangling threads at shutdown so I have to manually kill the app process after shutdown. The above does not look very sound.

Could the problem be that my tab object, essentially, has two owners? The main thread creates each tab object on the heap but a dispatched thread pool thread creates the tab object's QEventLoop on the heap. That would be design (a). It just now occurred to me to try another design, call it (b), by adding an intermediary class created by the main thread which receives a thread from the main thread's thread pool. In this class' run() function I could instantiate a tab such that the QEventLoop gets started with a call to exec() as the last statement in the tab object's constructor. In this way the tab object, including its event loop, is owned by a single thread.

So my main question comes to: which design should I pursue, (a) or (b), or should it be another design, say (c)?

If (a) I would be happy to provide testing results of various combinations and/or code. I will be working on (b) in the meantime. If (c), and if you have any suggestions, I would be most grateful.