| 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
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
Swift