Previously sharing a Timer/Notifier between threads (or just handing
its ownership to another thread) lead to a crash as they are
thread-specific.
This commit makes it so we can handle mutation (i.e. just deletion
or unregistering) in a thread-safe and lockfree manner.
This introduces a new TimeoutSet class for use in
EventLoopImplementationUnix. It is responsible for finding a timer that
expires the soonest and for firing expired timers. TimeoutSet expects
timeouts to be subclasses of EventLoopTimeout, of which EventLoopTimer
is now a subclass, obviously.
TimeoutSet stores timeouts in a binary heap, so
EventLoopImplementationUnix should handle large amounts of timers a lot
better now.
TimeoutSet also supports scheduling of timeouts whose fire time is
relative to the start of the next event loop iteration (i. e. ones
that directly bound polling time). This functionality will reveal its
full potential later with the implementation of asynchronous sockets but
it is currently used to implement zero-timeout timers that are an analog
of Core::deferred_invoke with slightly different semantics.
A typo in the changes to our userland timekeeping classes caused us to
make a syscall every time we want to check whether a timer is ready to
fire in `EventLoopManagerUnix::wait_for_events()`. Instead, only use
coarse time, and get it immediately before it is used in both cases.
This reduces CPU usage by an (eyeballed) 20-30% while playing back
video with VideoPlayer.
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
This shouldn't have been moved to EventLoopManager, as the manager is
global and one-per-process, and the implementation is one-per-loop.
This makes cross-thread event posting work again, and unbreaks
SoundPlayer (and probably other things as well.)
Things such as timers and notifiers aren't specific to one instance of
Core::EventLoop, so let's not tie them down to EventLoopImplementation.
Instead, move those APIs + signals & a few other things to a new
EventLoopManager interface. EventLoopManager also knows how to create a
new EventLoopImplementation object.
Using QEventLoop works for everything but it breaks *one* little feature
that we care about: automatically quitting the app when all windows have
been closed.
That only works if you drive the outermost main event loop with a
QCoreApplication instead of a QEventLoop. This is unfortunate, as it
complicates our API a little bit, but I'm sure we can think of a way to
make this nicer someday.
In order for QCoreApplication::exec() to process our own
ThreadEventQueue, we now have a zero-timer that we kick whenever new
events are posted to the thread queue.
The EventLoop is now a wrapper around an EventLoopImplementation.
Our old EventLoop code has moved into EventLoopImplementationUnix and
continues to work as before.
The main difference is that all the separate thread_local variables have
been collected into a file-local ThreadData data structure.
The goal here is to allow running Core::EventLoop with a totally
different backend, such as Qt for Ladybird.
