Inheritance from `EventReceiver` on the `Thread` class was only used in
the `BackgroundAction` class, where the children vector was keeping the
action alive until the work was completed. However, this can be
accomplished by instead capturing a `NonnullRefPtr` of `this`. The work
function can then avoid having to remove the `BackgroundAction` from
its parent `Thread` when the work completes.
The previous iteration of this API was somewhat odd and rough in random
places, which degraded usability and made less than perfect sense.
This commit reworks the API to be a little closer to more
conventional promise APIs (a la javascript promises).
Also adds a test to ensure the class even works.
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. :^)
