summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEdwin Mons <edwin.mons@isode.com>2019-11-19 09:04:47 (GMT)
committerEdwin Mons <edwin.mons@isode.com>2019-11-19 10:51:10 (GMT)
commit697ae6ae84512a744958b24118197ec7bfdbc1f0 (patch)
treea68474dea94266efc70b710fa02d5ce491b9045c /3rdParty/Boost/src/boost/fusion/view/reverse_view/detail
parent8230b23238b4d0ef0fcde01a799758558d502fa1 (diff)
downloadswift-697ae6ae84512a744958b24118197ec7bfdbc1f0.zip
swift-697ae6ae84512a744958b24118197ec7bfdbc1f0.tar.bz2
Let handleNextEvent only handle a single event
A batching mechanism was added to EventLoop::handleNextEvent, which caused it to be renamed to handleNextEvents. The problem with the batching was that it breaks EventLoop::removeEventsFromOwner: events already grabbed off the events_ queue for invocation could be removed, leading to issues in cases where two events were grabbed off the queue that referred to the same entity, the second event was a timer event, and the first event caused the timer to be stopped. The timer event would in this case be executed, leading to unexpected behaviour or crashes, as shown by the added unit test. Test-Information: Unit tests pass on Debian 9 and macOS 10.14. Benchmarked the eventloop on Debian and macOS, and did not notice a performance degradation. Transferred files using S5B and IBB, and checked there were no UI hangs. Transfer speed before and after the change are roughly the same. Change-Id: Ife7312f533e8f0976c2e8077d16e0b63fbac6eb1
Diffstat (limited to '3rdParty/Boost/src/boost/fusion/view/reverse_view/detail')
0 files changed, 0 insertions, 0 deletions