This change ensures that a reference to the BackgroundAction is held
until after the error callback has executed on the event loop.
This fixes an intermittent crash in Assistant :^)
As the user might want to have interactions with LibGUI while handling
errors, this code should be executed in the original `EventLoop`.
Similarly to what is done with the error-free path.
BackgroundActions are now added as a job to the event loop, therefore
they get canceled when the loop exits and their on_complete action never
runs. This fixes all UAF bugs related to BackgroundAction's use of
EventLoops, as seen with e.g. thumbnail generation.
This patch allows returning an `Error` from the `on_complete` callback
in `BackgroundAction`.
It also adds a custom callback to manage errors returned during its
execution.
Because the wake pipe is thread-local, it was previously not possible
to wake an event loop across a thread. Therefore, this commit
rearchitects event loop waking by making the wake function a member of
the event loop itself and having it keep a pointer to its thread's wake
pipe. The global wake() function calls wake on the current thread's
event loop.
This also fixes a bug in BackgroundAction: it should wake the event loop
it was created on, instead of the current thread's event loop.
We now capture the origin thread's current event loop when setting up
a BackgroundAction and then invoke the on_complete callback on that same
event loop.
Core::deferred_invoke is a way of executing an action after previously
queued events have been processed. It removes the requirement of
having/being a Core::Object subclass in order to defer invocation
through Core::Object::deferred_invoke.
Core::Object::deferred_invoke now delegates to Core::deferred_invoke.
The version with the Object& argument is still present but will be
removed in the following commits.
This commit additionally fixes a new places where the
DeferredInvocationEvent was dispatched to the event loop directly, and
replaces them with the Core::deferred_invoke equivalent.
We need to move the result out of the BackgroundAction object before
posting the completion callback as there is a chance the
BackgroundAction instance gets freed before the event loop runs our
callback.
Fixes#7641
The worker thread used for BackgroundAction was going to sleep for
1 second at a time (when there was nothing to do.) This made using
background actions for anything interactive quite unresponsive since
you had to wait up to 1 second before it even started on your task.
We now use a simple Unix pipe to signal the worker thread that a new
work item is available.
This makes Assistant way more responsive when typing. :^)
