while testing Heran's patch on Windows I found strange bug.
The build of QT Windows does some handy checks, which are probably
hard to implement in Posix.
While closing the connection I got run-time error:
ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to
objects owned by a different thread. Current thread 9601b78. Receiver
'' (of type 'toConnection') was created in thread 24c7c00", file
kernel\qcoreapplication.cpp, line 349
The issue is quite complex.
- the commit 4021 implemented new class toConnectionDeleter. See:
mrjohnson0 8/7/2011 11:21:39 PM
Don't close connections on the main thread. oracle in particular
blocks while closing until all statements finish, even after
attempting to cancel. This can be a real bummer if the cache query is
- Background thread calls:
toConnectionPool::~toConnectionPool() <-- here we're screwed
- toConnectionPool is subclass of QObject. So when it is deleted
it notifies it's parent about own disposal. It calls
ChildEvent e(QEvent::ChildRemoved, q);
In this moment Qt detects that the instance of toConnection was created
within context of different thread and therefore throws run-time error.
The parent is instance of the toConnection which is also being deleted.
This can be a source of some random crashes even on Linux.
The question is how this can be solved?
1. toConnectionPool will not be a subclass of QObject.
Do we really need this feature?
2. toConnectionDeleter is not needed at all. The connection can be
instantly closed from the main thread.
OCI API allows you to call OCIBreak, OCIReset from any thread even
if the connection is currently used
by another thread. I'm afraid that this approach can lead to
SEGFAULTs inside OTL.
Before we call "delete ConnectionPool;" we call
but cancelAll in fact does nothing. If the connection is marked
"busy" no OCIBreak is executed.
3. Maybe there is some mighty trick in QT object model that can avoid calling
sendEvent from destructor of the toConnectionPool.
This message was sent using IMP, the Internet Messaging Program.