| Age | Commit message (Collapse) | Author |
|---|
|
Code review makes me think that if the timer fires at the same time as
stop() is called, it would be possible for the clearing of events from
the loop to happen before the event is put into the loop, leading to
the sort of crashes we've seen with timers firing and access exceptions.
I can't reproduce those to know if this fixes them, and I'm not even sure
I'm not being dense thinking this patch fixes a real issue.
Test-Information:
Unit tests pass
Change-Id: I76337d5556a9c3902d5c2f4da754ae657810d436
|
|
According to boost doucmentation shared deadline_timers are not
thread-safe. Adding a mutext to protect access to
boost::asio::deadline_timer instance in Swift::BoostTimer.
This fixes a data-race reported by TSAN when running
Swiften/QA/ClientTest/ClientTest.
Test-Information:
Verified that the data-race report is gone with this fix.
Change-Id: I62c8c3a07d6ea16fe6e2d24c879340040406699b
|
|
Test-Information:
Tested build on Windows 8 with VS 2014 and ran unit tests.
Change-Id: I3d8096df4801be6901f22564e36eecba0e7310c4
|
|
Change-Id: I94ab4bbb68c603fe872abeb8090575de042f5cb4
|
|
|
|
|
|
This should avoid problems when destroying an event loop containing
timer or network events, after the network factory (and io_service
object) has disappeared (i.e. at shutdown).
|
|
The event loop now needs to be explicitly passed to clients
using it.
|
|
BoostTimer isn't supposed to be constructed as a non-shared-ptr. Making
constructor private to avoid this error in the future.
|
|
|
|
|
|
|
|
|
|
|
Swift