| Age | Commit message (Collapse) | Author |
|---|
|
The old event loop had this protection, however it is
missing in the new design. This adds this protection again
as some external event loop implementations, e.g. the Qt
event loop, directly process their event queue from an event
handler.
Test-Information:
Unit and system tests pass on OS X 10.11.3.
Change-Id: I10ce7160c3f201e2d5f53ab8289ddde1eb3262e8
|
|
Test-Information:
Unit and integration tests pass on OS X 10.10.5 and Debian 8.2.
UI remains responsive when transferring a file between two
Swift instances.
Change-Id: I7841347a5d6c55121e02e274a7087a2fc200f879
|
|
The new event loop design has a single event queue that is
synchronized to protect against data races.
The removal of events in the queue by EventOwner is
deterministic.
Test-Information:
All unit and integration tests with TSAN and
cxxflags=-DBOOST_SP_USE_PTHREADS on Debian 8.2 pass without
reports.
Multiple Swiften/QA/ClientTest/ClientTest runs under
different CPU stress caused no TSAN reports on Debian 8.2.
Swift itself only causes TSAN reports related to Qt itself,
out of our control, and most likely false positives, i.e.
TSAN not detecting the synchronization method inside Qt
correctly.
Unit tests pass without errors and successfully connected
to Slimber on OS X 10.10.5.
Change-Id: Ia1ed32ac2e758c5b9f86e0dac21362818740881e
|
|
Change-Id: I94ab4bbb68c603fe872abeb8090575de042f5cb4
|
|
Includes fixes to:
Build with new Visual Studio and Boost
Avoid error caused when Avahi is present but Qt is not
Make declaration of XMPPRosterImpl::addContact consistent with implementation
Includes enhancements to:
Allow user-configurable mt.exe
Allow splitting openssl paths
Allow disabling gconf lookup
Make idn support optional
Allow disabling various library detections
Remove use of non-Python2.4 features in sconscripts
Test-Information:
Builds
Change-Id: Iee91ee80291a8bdf87cc169c915e4dad1cc1055b
|
|
Change-Id: I6d2364dc85464f238d95978793f35953a2947799
|
|
All applications succesfully link against Swiften.dll.
|
|
|
|
|
|
When EventLoop::handleEvent() was called recursively (i.e. by calling
processEvents() from a slot), weird things happened, especially in the
XMPP parser (assertion triggers, parse error from server, ...). Now, callbacks
are put in a queue handled by the topmost handleEvent.
Resolves: #592, #568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Swift