| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes Qt work on VxWorks 6.6+ in native (kernel) mode.
* compiles with the WindRiver GNU toolchain (Linux only)
* works with QWS (tested with the VNC driver only)
* tested on PPC hardware and the x86 VxWorks simulator
* no q3support, no phonon, no webkit
* no QSharedMemory, no QSystemSemaphore, no QProcess
* only one QApplication instance (flat address space)
* filesystem support depends heavily on the quality of the native driver
* QLibrary is just a dummy to make plugins work at all
* qmake transparently creates VxWorks munching rules for static ctors
* made auto-test cope with missing OS features
A special note regarding the Q_FOREACH patch for dcc:
when calling foreach(a,c) with c being a function returning a container,
the compiler would generate 5 references to some labels (.LXXXX), which
are not there (so the linker complains in the end).
Seems like dcc doesn't really like the 'true ? 0 : <function call to get type>'
statement
Reviewed-By: Harald Fernengel
|
| |\ |
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That way we prevent the current possible race condition that may appears
while touching signals slot while object are moved to different threads.
For exemple, when we do sender->threadData->mutex->lock(); the sender
can possibly be moved to another thread between the moment we get the
pointer to the threadData and the moment we aquire the lock. We could
check if we locked the right mutex and retry otherwise, but that would
break if the threadData (and hence the mutex) get destroyed in between.
The per object mutex is implemented with a thread pool.
I'm not using the global QThreadPool because we might ends up locking
two of their mutex, and that would be dangerous if something else holds
a lock on the same mutex (possible deadlock)
Putting the mutex pool in a Q_GLOBAL_STATIC doesn't work as it might
result of the ppol being deleted before some other object in others
Q_GLOBAL_STATIC structures
There is no need to lock this mutex in moveToThread as this is safe.
When emiting a signal, we do not need to lock the thread data, as the
user must ensure that the object is not moved to a thread while emiting
a AutoConnection signal.
Reviewed-by: Brad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
while using QOrderedMutexLocker::relock we might unlock our mutex
protecting the 'senders' list for a short moment. Another thread may then
modify or remove element on the list.
Therefore, we need to recheck the consistency of the list once we did
that.
Also, we cannot call removeSender because that will remove every
connections, making impossible for another object destroyed in the same
time to clean up the senders list, so call derefSender instead.
Reviewed-by: Brad
|
| |
|
