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.
Installing resources directly under ${prefix}/share causes conflicts
with other packages. This will become more problematic whenever Ghostty
is opened and becomes packaged in distributions.
Instead, install all resources under a "ghostty" subdirectory (i.e.
${prefix}/share/ghostty). This includes themes, shell integration, and
terminfo files.
Only "/usr/share" style paths use the "ghostty" subdirectory. On macOS,
Ghostty is already isolated within its app bundle, and if
$GHOSTTY_RESOURCES_DIR is set then we assume that points to the actual
resources dir (without needing to append "ghostty" to it).
