diff options
author | Edwin Mons <edwin.mons@isode.com> | 2019-11-19 09:04:47 (GMT) |
---|---|---|
committer | Edwin Mons <edwin.mons@isode.com> | 2019-11-19 10:51:10 (GMT) |
commit | 697ae6ae84512a744958b24118197ec7bfdbc1f0 (patch) | |
tree | a68474dea94266efc70b710fa02d5ce491b9045c /3rdParty/Boost/src/boost/proto/functional | |
parent | 8230b23238b4d0ef0fcde01a799758558d502fa1 (diff) | |
download | swift-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/proto/functional')
0 files changed, 0 insertions, 0 deletions