This commit does three things atomically:
- switch over Core::Account+SystemServer+LoginServer to sid based socket
names.
- change socket names with %uid to %sid.
- add/update necessary pledges and unveils.
Userland: Switch over servers to sid based sockets
Userland: Properly pledge and unveil for sid based sockets
Core::Acount is only used within ``#ifdef __serenity__`` blocks in these
files, so guard the inclusion of Account.h in the same way.
This fixes the Android build of these files.
The audio enqueuer thread goes to sleep when there is no more audio data
present, and through normal Core::EventLoop events it can be woken up.
However, that waking up only happens when the thread is not currently
running, so that the wake-up events don't queue up and cause weirdness.
The atomic variable responsible for keeping track of whether the thread
is active can lead to a racy deadlock however, where the audio enqueuer
thread will never wake up again despite there being audio data to
enqueue. Consider this scenario:
- Main thread calls into async_enqueue. It detects that according to the
atomic variable, the other thread is still running, skipping the event
queue wake.
- Enqueuer thread has just finished playing the last chunk of audio and
detects that there is no audio left. It enters the if block with the
dbgln "Reached end of provided audio data..."
- Main thread enqueues audio, making the user sample queue non-empty.
- Enqueuer thread does not check this condition again, instead setting
the atomic variable to indicate that it is not running. It exits into
an event loop sleep.
- Main thread exits async_enqueue. The calling audio enqueuing system
(see e.g. Piano, but all of them function similarly) will wait until
the enqueuer thread has played enough samples before async_enqueue is
called again. However, since the enqueuer thread will never play any
audio, this condition is never fulfilled and audio playback deadlocks
This commit fixes that by allowing the event loop to not enqueue an
event that already exists, therefore overloading the audio enqueuer
event loop by at maximum one message in weird situations. We entirely
get rid of the atomic variable and the race condition is prevented.
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.
The main event loop functionality was used in just two places where the
alternative is a bit simpler. Remove it in favor of referencing the
event loop directly, or just invoking `EventLoop::current()`.
Note that we don't need locking in the constructor since we're now only
modifying a thread-local `Vector`. We also don't need locking in the
old call sites to `::with_main_locked()` since we already lock the
event loop in the subsequent `::post_event()` invocation.
For now, EventLoop and Application still have a make_inspectable
parameter, so that when working on an application you can temporarily
hard-code it to be inspectable rather than having to set the env var
each time.
A mistake I've repeatedly made is along these lines:
```c++
auto nread = TRY(source_file->read(buffer));
TRY(destination_file->write(buffer));
```
It's a little clunky to have to create a Bytes or StringView from the
buffer's data pointer and the nread, and easy to forget and just use
the buffer. So, this patch changes the read() function to return a
Bytes of the data that were just read.
The other read_foo() methods will be modified in the same way in
subsequent commits.
Fixes#13687
If we find a timer that needs to be fired immediately, we can stop
looking through the remaining timers.
This significantly reduces time spent in get_next_timer_expiration()
on ACID3. Of course, with a better data structure, we could reduce
time spent further. I've left a FIXME about that.
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.
Previously, event loop stacks on non-main threads would always crash
because the condition for "am I the lowest-stacked loop" was still
"am I the main loop", which of course is no longer sensible. A simple
switch to `is_instantiated` fixes this.
It's a bad idea to have a global event loop in a client application as
that will cause an initialization-order fiasco in ASAN. Therefore, LibC
now has a flag "s_global_initializers_ran" which is false until _entry
in crt0 runs, which in turn only gets called after all the global
initializers were actually executed. The EventLoop constructor checks
the flag and crashes the program if it is being called as a global
constructor. A note next to the VERIFY_NOT_REACHED() informs the
developer of these things and how we usually instantiate event loops.
The upshot of this is that global event loops will cause a crash before
any undefined behavior is hit.
The event loop is responsible for handling POSIX signals while it's
running. The signal handler adds the signals to a wake pipe which is
then read after the select'ing code in wait_for_event. Problems happen,
however, when another signal comes in after the select wake: the signal
will interrupt the next syscall, the `read` from the wake pipe, and the
resulting EINTR in wait_for_event causes the program to crash. This is
undesirable. Instead, we want to retry reading as long as we're
interrupted.
After the previous change, the wake pipe was only being created on the
main thread by the main event loop. This change utilizes a flag to
always initialize the wake pipe on other threads. Because the pipe is
quite expensive (it will count towards the file descriptor limit, for
instance), we do the initialization "lazily": Only when an event loop is
constructed and it notices that there hasn't been a wake pipe created on
its thread, it will create the pipe. Conversely, this means that there
are no pipes on threads that never use an event loop.
The event loop system was previously very singletony to the point that
there's only a single event loop stack per process and only one event
loop (the topmost) can run at a time. This commit simply makes the event
loop stack and related structures thread-local so that each thread has
an isolated event loop system.
Some things are kept at a global level and synchronized with the new
MutexProtected: The main event loop needs to still be obtainable from
anywhere, as it closes down the application when it exits. The ID
allocator is global as IDs should not be shared even between threads.
And for the inspector server connection, the same as for the main loop
holds.
Note that currently, the wake pipe is only created by the main thread,
so notifications don't work on other threads.
This removes the temporary mutex fix for notifiers, introduced in
0631d3fed5 .
This fixes a CI flake we've been seeing lately in TestLibCoreStream.
The solution itself is somewhat of a stop-gap as there are more thorough
event loop threading improvements in the works.
Sometimes, pumping the event loop will cause new events to be
generated. For example, an IPC message could be delivered which then
dispatches a new event to be handled by the GUI. To the invoker of
`EventLoop::pump()`, it is not obvious if any events were processed at
all.
Libraries like SDL2 might not have the opportunity to run the event
loop often enough that events can be processed swiftly, since it might
spend time doing other things. This can result in stuttering GUI
interactions.
This changes `EventLoop::pump()` to return the number of processed
events. This functionality will be used by our SDL2 port in another PR.
Also add slightly richer parse errors now that we can include a string
literal with returned errors.
This will allow us to use TRY() when working with JSON data.
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
The main event loop pushes itself onto the event loop stack, and so it
should also pop itself when destroyed.
This will surface attempts to use the event loop stack after the main
event loop has been destroyed.
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.
This static bool getter can be used to VERIFY that an event loop exists,
in situations where one is expected.
This is helpful if the absence of an event loop would generate strange
and/or loud errors that don't immediately point to this as a cause.
Core::EventLoop now makes an outbound connection to InspectorServer
instead of listening for incoming connections on a /tmp/rpc/PID socket.
This has many benefits, for example:
- We no longer keep an open listening socket in most applications
- We stop leaking socket files in /tmp/rpc
- We can tighten the pledges in many programs (patch coming)
The LOCKER() macro appears to have been added to LibThread as a
userspace analog to the previous LOCKER() macro that existed in
the kernel. The kernel version used the macro to inject __FILE__ and
__LINE__ number into the lock acquisition for debugging. However
AK::SourceLocation was used to remove the need for the macro. So
the kernel version no longer exists. The LOCKER() in LibThread doesn't
appear to actually need to be a macro, using the type directly works
fine, and arguably is more readable as it removes an unnecessary
level of indirection.
