Age | Commit message (Collapse) | Author |
|
This allows execution of events inside an existing io_service
if an application is already using Boost ASIO for other things
and can share the io_service.
Test-Information:
Builds on OS X 10.11.2.
Change-Id: I092ed7a25b24ef95d4664bae98ed84cc0f149073
|
|
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
|
|
The data race is on the events_ member in DummyEventLoop.
A BoostIOServerThread can post events to the DummyEventLoop and thereby
access its events_ data member while the test's main code processes
events of the loop.
To prevent access to the DummyEventLoop by the BoostIOServiceThread
after the DummyEventLoop is deleted, the BoostIOServiceThread is
deleted before the DummyEventLoop.
Process remaining events in BoostConnectionTest::tearDown like we do in
BoostConnectionServerTest::tearDown.
Test-Information:
Run multiple times on NetworkTest as TSAN enabled build on Linux.
Without the patch it reports a data race for the events_ deque member.
Change-Id: I3c85535338fc0ce0263dbfc3534aceb1dd09c137
|
|
Test-Information:
Unit tests run successfully.
Change-Id: I5df196c8bc642eeff4997558c3c56c6fa03bef16
|
|
Change-Id: I94ab4bbb68c603fe872abeb8090575de042f5cb4
|
|
Change-Id: I2494ca43f30c3a7e90fe38f20df421e53972974c
|
|
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
|
|
This is necessary for supporting 'legacy' Objective-C
runtimes (e.g. OS X 32-bit).
Partly reverts 88153286ea2f11fea24b950e7dbb0075ceb49a54.
Change-Id: Ibc6e1dad255ae8e36b946ef4c792c0f272c73d71
|
|
Change-Id: Icd510a0737c46618acedc311b1b4e24b72d6673d
|
|
Change-Id: I36e82dfe1ec492df719bcc85e5549fb4013a6723
|
|
Change-Id: I1ea6c42292b7c3b5f0ecdc1395b9c8e8cf17a6b9
|
|
Move instance variables to implementation because they are deprecated to have in the interface. Requires 'Modern' obj-c runtime.
Change-Id: I60d693b7966e08ccc003818ab51ea3633c90ae17
License: This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
|
|
Change-Id: I1d74324515b20e0dc3d0ef4aa2f556fea7b4bee3
License: This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.s
|
|
Change-Id: Iad90ae18911116603888ee5dc332151c24a7cf60
|
|
Change-Id: I70109624b4bd7aab9ba679a3eaabc225dd64a03a
|
|
Change-Id: I6d2364dc85464f238d95978793f35953a2947799
|
|
Change-Id: I8690af82a7f73d3883057b2a58a19197d6b09842
|
|
All applications succesfully link against Swiften.dll.
|
|
License: This patch is BSD-licensed, see http://www.opensource.org/licenses/bsd-license.php
|
|
|
|
Tweaked the sources to satisfy cppcheck.
|
|
|
|
|
|
|
|
|
|
|
|
Resolves: #798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The event loop now needs to be explicitly passed to clients
using it.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|