The recent `pwnkit` exploit brought this to my attention, not that we
are a setuid process we should still do this properly... who knows where
this code might get used in the future.
In unbounded mode, the read and write pointers are free to move
independently of one another. This is useful where the input and output
streams are progressing at the same rate on average, and we want to keep
the latency stable in the event than an underrun or overrun occurs.
If an underrun occurs (i.e., there is not enough data in the buffer to
satisfy a read request), the missing values with be filled with zeros. When
the writer catches up, the same number of values will be skipped from the
input.
If an overrun occurs (i.e., there is not enough free space in the buffer to
satisfy a write request), excess values will be discarded. When the reader
catches up, the same number of values will be zeroed in the output.
Unbounded mode is currently unused since our audio input and output
streams are not synchronised. This will be implemented in a later commit.
Also reimplemented as a lock-free queue which is safer for use in audio
device callbacks.
Now LG uses a 25Hz tick timer it is an issue that `create_timer` spawns
a new thread for every single timer event, so instead multiplex all the
timers into a single thread with a 1ms resolution.
This change allows the host to provide information to the client about
how the VM is configured, information such as the UUID, CPU
configuration and capture method both for informational display in the
client as well as debugging in the client's logs.
The format of the records allows this to be extended later with new
record types without needing to bump the KVMFR version.
As the ringbuffer is now in use for audio it makes sense to provide bulk
append and consume functions that are thread safe instead of adding
locking over all of the functions. This partially reverts the prior
commit that added the extra locking.
Sometimes, e.g. when xdg-open has to start the browser, the xdg-open
process can stay around until the browser exits, which freezes the
client. Instead, we should not wait for xdg-open to exit.
However, we can't simply not call wait, as that would leave the
xdg-open process around as a zombie. We could turn off the SIGCHLD
handler, but that's a global solution to a local problem. Instead, we
call setsid and fork again to detach the xdg-open process as if it's a
daemon, and let init take care of the reaping process.
Co-Authored-By: Tudor Brindus <me@tbrindus.ca>
The old code will not correctly report the number of threads on CPUs with
more than one processor group, i.e. when there are more than 64 logical
processors (threads).
