Previously, a `Thread` could be deleted while its action was running,
even if it was running detached.
By changing it to be atomically reference counted, and incrementing the
count when starting the action, we can keep the Thread and its running
action `Function` alive until it exits. Thus, detached `Thread` objects
can be deleted by the thread creating them and allowed to die
naturally.
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.
Since Core::Object properties are really only used by GML now that the
Inspector is long gone, there's no need for these to pollute
Core::Object.
This patch adds a new GUI::Object class to hold properties, and makes
it the new base class of GUI::Window, GUI::Widget and GUI::Layout.
The "instantiate an object by name" mechanism that GML uses is also
hoisted into GUI::Object as well.
Contrary to the log message that was shown, it is not decidedly a logic
error to detach a thread that has exited. Even in the simple unit tests
we have, it's possibly for the thread to run and exit in between the
time it takes for our call to Thread::start() to complete and
Thread::detach() to run. This is often seen on CI.
This replaces all state-related variables with a single ThreadState.
These are simplified over what the Kernel has, but capture all
userspace-available thread state.
Locking the state behind an atomic and using proper atomic operations
also gets rid of quite some deadlocks and race conditions that have
existed around m_tid and others beforehand.
In terms of behavior, this introduces the following changes:
- All thread state mishandling (e.g. joining a detached thread) crashes
the program. Mishandling thread state is a severe kind of concurrency
bug that might also be indeterministic, so letting it silently
disappear with the return value of pthread_ APIs is a bad idea. The
thread state can always be checked beforehand to ensure that no crash
happens.
- Destructing a still-running thread will crash in AK/Function, so the
Thread destructor issues its own warning for debugging purposes.
- Thread issues warnings before crashes in many places to aid
concurrency debugging (the most difficult kind of debugging).
- Joining dead but not detached threads is legal, as per POSIX APIs.
- The thread ID is never reset to 0 after the thread has been started
and subsequently been assigned a valid thread ID. The thread's exit
state is still obtainable.
- Detaching threads that are about to exit is considered a programming
bug and will often (not always, as we can't catch all execution
sequences involved in such a situation) crash the program on purpose.
If you want to detach a thread that will definitely exit on its own,
you have to prevent it from exiting before detach() was called (e.g.
with an "exit requested" flag).
pthread_setname_np is a can of worms for portability. Linux, macOS,
and the BSDs all do it differently.
Also skip adding the tid as an inspectable Core::Object property on
systems where pthread_t is known to be a pointer.
Users can now determine whether a thread has been started or not. A
started thread might also have already terminated.
Implementation note: We *could* detect this with pthread APIs maybe, but
this is much simpler.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Sometimes you don't care about `joining()` the result of a thread. The
underlying pthread implementation already existed for detaching and
now we expose it to the higher level API.
