This sets the macOS QoS class of the renderer thread. Apple
recommends[1] that all threads should have a QoS class set, and there
are many benefits[2] to that, mainly around power management moreso than
performance I'd expect.
In this commit, I start by setting the QoS class of the renderer thread.
By default, the renderer thread is set to user interactive, because it
is a UI thread after all. But under some conditions we downgrade:
- If the surface is not visible at all (i.e. another window is fully
covering it or its minimized), we set the QoS class to utility. This
is lower than the default, previous QoS and should help macOS
unschedule the workload or move it to a different core.
- If the surface is visible but not focused, we set the QoS class to
user initiated. This is lower than user interactive but higher than
default. The renderer should remain responsive but not consume as
much time as it would if it was user interactive.
I'm unable to see any noticable difference in anything from these
changes. Unfortunately it doesn't seem like Apple provides good tools to
play around with this.
We should continue to apply QoS classes to our other threads on macOS.
[1]: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon?preferredLanguage=occl
[2]: https://blog.xoria.org/macos-tips-threading/
I hit an edge case when using Private Wi-Fi addressing on macOS where
the last section of the randomized mac address starts with a '0'. The
hostname parsing for the shell integration didn't handle this case, so
issue #2512 reappeared.
This fixes that by explicitly handling port numbers < 10.
Note that this includes some failing tests because I want to make the
uri handling better and more specific. It's a little bit too general
right now so I want to lock it down to:
1. macOS only; and
2. valid mac address values
because that's how the macOS private Wi-Fi address thing works;
randomizes your mac address and sets that as your hostname.
Fixes#2432
On macOS, processes with an NSApplicationMain entrypoint do not have
access to libc argc/argv. Instead, we must use NSProcessInfo. This
commit introduces an args iterator that uses NSProcessInfo, giving us
access to the args.
This also fixes an issue where we were not properly skipping argv0 when
iterating over the args. This happened to be fine because we happened to
ignore invalid args but it introduces a config error.
To protect your system and ghostty from misbehaving programs that launch
too many processes for the system to handle (e.g. like a fork bomb),
this implements an option to limit the number of processes that can be
started in a surface.
A fork bomb for example or other misbehaving program would then only
take down one surface and not the entire system.
Side node:
If I am right in issue #2084, this feature does not actually work on a
per surface basis but on all surfaces. If this is the case, it could
probably be fixed together. Chances are, that I am wrong though 😉
Further improvements that could be done:
- unify way to set cgroup attributes
- set sane default: 10% of system max?
Quoting `man man`:
> If MANPATH begins with a colon, it is appended to the default list;
Alternatively we can think about:
> if it ends with a colon, it is prepended to the default list;
To take preference over existing values, but that shouldn't be really a
problem, as there rather isn't much of another projects named `ghostty`.
Use clone3 / CLONE_INTO_CGROUP to have the Linux kernel create the process in the
correct cgroup rather than move the process into the cgroup after it is created.
Some opener commands (like macOS's open) finish immediately after
running, while others (xdg-open) do not, staying alive until the
application that was opened itself terminates.
For now, we explicitly state whether or not we should wait for a
command. Eventually we may want to do something more generic (e.g. wait
for some predetermined amount of time and if the process does not
complete, give up without collecting stderr).
NSFileManager has offered a homeDirectoryForCurrentUser property since
macOS 10.12. Using that is preferable to running a directory service
child process.
On Windows, the tmpDir function is currently using a buffer on the stack
to convert the WTF16-encoded environment variable value "TMP" to utf8
and then returns it as a slice...but that stack buffer is no longer valid
when the function returns. This was causing the "image load...temporary
file" test to fail on Windows.
I've updated the function to take an allocator but it only uses
the allocator on Windows. No allocation is needed on other platforms
because they return environment variables that are already utf8 (ascii)
encoded, and the OS pre-allocates all environment variables in the process.
To keep the conditional that determines when allocation is required, I
added the `freeTmpDir` function.
This gets `zig build -Dtarget=aarch64-ios` working. By "working" I mean
it produces an object file without compiler errors. However, the object
file certainly isn't useful since it uses a number of features that will
not work in the iOS sandbox.
This is just an experiment more than anything to see how hard it would be to
get libghostty working within iOS to render a terminal. Note iOS doesn't
support ptys so this wouldn't be a true on-device terminal. The
challenge right now is to just get a terminal rendering (not usable).
Fixes#1146
I can't remember why we did this before. The comment in question makes
sense if we were trying to set cur to infinity but doesn't make sense to
me why we'd change max. Removing this doesn't seem to cause any issues
so lets give it a shot.
