I had to move the thread list out of the protected base area of Process
so that it could live with its lock (which needs to be mutable).
Ideally it would live in the protected area, so maybe we can figure out
a way to do that later.
When I laid down the foundation for the start of the big process lock
separation, I added asserts to all system call implementations to
validate we hold the big process lock in the locations we think we
should be.
Adding that assert to sys$profiling_enable broke boot time profiling as
we were never holding the lock on boot. Even though it's not technically
required, lets make sure to hold the lock while enabling to appease the
assert.
VirtualConsole::m_lock was only used in a single place: on_tty_write()
That function is already protected by a global lock, so this second
lock served no purpose whatsoever.
I use the `configure-components` functionality locally during
development. There are a few services (SpiceAgent) which aren't marked
as required components, and hence aren't built in all configurations,
but we still try to launch them in all configurations.
Instead of letting the forked SystemServer process crash, lets
gracefully handle the situation of a missing binary and provide a
message to the user.
As this is a test machine I use personally to test "modern" hardware
setups, it feels quite comfortable to not care too much about VGA with
this type of machine.
Also, we don't actively use the IDE controller on this machine type, so
let's just remove it :^)
Note: TCPSocket::create_client() has a dubious locking process where
the sockets by tuple table is first shared lock to check if the socket
exists and bail out if it does, then unlocks, then exclusively locks to
add the tuple. There could be a race condition where two client
creation requests for the same tuple happen at the same time and both
cleared the shared lock check. When in doubt, lock exclusively the
whole time.
A protected value is a variable with enforced locking semantics. The
value is protected with a Mutex and can only be accessed through a
Locked object that holds a MutexLocker to said Mutex. Therefore, the
value itself cannot be accessed except through the proper locking
mechanism, which enforces correct locking semantics.
The Locked object has knowledge of shared and exclusive lock types and
will only return const-correct references and pointers. This should
help catch incorrect locking usage where a shared lock is acquired but
the user then modifies the locked value.
This is not a perfect solution because dereferencing the Locked object
returns the value, so the caller could defeat the protected value
semantics once it acquires a lock by keeping a pointer or a reference
to the value around. Then again, this is C++ and we can't protect
against malicious users from within the kernel anyways, but we can
raise the threshold above "didn't pay attention".
This is some syntaxic sugar to use a ContendedResource object with
reference counting. This effectively dissociates merely holding a
reference to an object and actually using the object in a way that
requires locking it against concurrent use.
This container is the same as IntrusiveList, except that it allows
modifications to the elements even if the reference to the
IntrusiveList itself is const, by returning mutable iterators. This
represents a use-case where we want to allow modifications to the
elements while keeping the list itself immutable.
This behavior is explicitely opt-in by using IntrusiveListRelaxedConst
instead of IntrusiveList. It will be useful later on when we model
shared/exclusive locks with the help of const and mutable references.
This allows one to set their desired parameters for run.sh without the
need to set them in every terminal session or add it to the user account
shell files. If a run-local.sh file exists at the repository root and is
executable, it will be sourced. The file can contain any variables that
are expected to be set in run.sh.
length is size_t as returned, and so subtracting from it may cause
underflow. We handle this case by just casting it to a signed value, and
the for loop predicate takes care of the rest.
This patch adds the logic for the GuideTool. Pulling in from outside the
image creates a new Guide, moving a Guide outside of the image deletes
it and a Guide can be deleteted via the context menu.
A Guide is considered clicked when the cursor is less than 20 pixels
away from the line.
