Swiftdiff 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 /Swiften/EventLoop/EventLoop.h | |
| 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 'Swiften/EventLoop/EventLoop.h')
| -rw-r--r-- | Swiften/EventLoop/EventLoop.h | 11 |
1 files changed, 5 insertions, 6 deletions
diff --git a/Swiften/EventLoop/EventLoop.h b/Swiften/EventLoop/EventLoop.h index 06b9fbb..f61b9bc 100644 --- a/Swiften/EventLoop/EventLoop.h +++ b/Swiften/EventLoop/EventLoop.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010-2016 Isode Limited. + * Copyright (c) 2010-2019 Isode Limited. * All rights reserved. * See the COPYING file for more information. */ @@ -43,21 +43,20 @@ namespace Swift { protected: /** - * The \ref handleNextEvents method is called by an implementation of the abstract \ref EventLoop class + * The \ref handleNextEvent method is called by an implementation of the abstract \ref EventLoop class * at any point after the virtual \ref eventPosted method has been called. * This method does not block, except for short-time synchronization. - * It can process multiple events before it reutrns. * If called recursively, the event queue is not further processed. Instead, \ref eventPosted * is called to notify the implementing event loop of the non-empty event queue. - * It is recommended to not call \ref handleNextEvents inside an event posted to the event loop + * It is recommended to not call \ref handleNextEvent inside an event posted to the event loop * as this can lead to an infinite loop. */ - void handleNextEvents(); + void handleNextEvent(); /** * The \ref eventPosted virtual method serves as notification for when events are still available in the queue. * It is called after the first event is posted to an empty queue or after an event has been handled in - * \ref handleNextEvents and there are still remaining events in the queue. + * \ref handleNextEvent and there are still remaining events in the queue. */ virtual void eventPosted() = 0; |