The wrapper struct ensures ensures the child process spawned for
the ProxyCommand is cleaned up under all the various error scenarios
(such as auth failures etc), as well as in the normal successful use
case. This includes killing it if necessary, and then waiting for it.
smol-potat hasn't had updates in 4 years and was bifurcating some
big deps. It wasn't necessary; it was trivially easy to replace
with smol::block_on with no meaningful increase in boilerplate,
and the result is much more understandable in purpose and effect.
This commit expands the set of data that we track for each client to
include the SSH_AUTH_SOCK. This defaults to the value of that env var on
the machine where the ClientId is constructed, which may be remote from
the mux server.
For the proxy scenario, a remote SSH_AUTH_SOCK path is not addressable,
and what we really want is the local SSH_AUTH_SOCK path from that SSH
session, so we introduce awareness of whether the current session is a
proxy session. Proxy sessions register the mux-local-proxy-id during the
setup of the proxy, but we don't apply the identity to the mux. Instead,
we wait for the remote client to send their identity and that is
annotate to show that it has been routed via a proxy and, crucially, has
the SSH_AUTH_SOCK replaced with the mux-local-proxy-id SSH_AUTH_SOCK.
```
; wezterm cli list-clients
USER HOST PID CONNECTED IDLE WORKSPACE FOCUS SSH_AUTH_SOCK
wez foo 336500 86.944834352s 944.834352ms default 3 /home/wez/.1password/agent.sock
wez foo (via proxy pid 337457) 337314 1.944834352s 944.834352ms 4 /tmp/ssh-XXXXTfGSp7/agent.337456
```
For the SSH_AUTH_SOCK to be populated, ssh agent forwarding also needs
to be enabled for SSH exec() calls; previously it was enabled only for
pty channels.
Since this commit changes the ABI of the mux protocol, the codec
version has been bumped.
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
and fixup some imports, which obscure the heart of this change!
The key thing is: we no longer unconditionally write directly to stderr;
use eprintln so that the test harness can capture stderr.
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
Continuing from the previous commit, this shifts:
* In-memory data -> temporary file
* Image decoding -> background thread
The background thread asynchronously decodes frames and
sends them to the render thread via a bounded channel.
While decoding frames, it writes them, uncompressed, to
a scratch file so that when the animation loops, it is
a very cheap operation to rewind and pull that data
from the file, without having to burn CPU to re-decode
the data from the start.
Memory usage is bounded to 4 uncompressed frames while
decoding, then 3 uncompressed frames (triple buffered)
while looping over the rest.
However, disk usage is N uncompressed frames.
refs: https://github.com/wez/wezterm/issues/3263
Need to use a newer version of libssh-rs that can report this state,
as the underlying libssh doesn't fold it into the process exit
status.
refs: https://github.com/wez/wezterm/issues/3095
Adapt the code we were using for libssh2 and use it for both
libssh and libssh2 so that we have consistent proxy command
support on both unix and windows, and both versions of the
ssh libraries.
This may help resolve the linked issue on windows, or at least,
uncover the next layer of problem(s).
refs: https://github.com/wez/wezterm/issues/3083
The tcgetpgrp call appears to have high variance in latency, ranging
from 200-700us on my system.
If you have 10 tabs and mouse over the tab bar, that's around 7ms
spent per frame just figuring out the foreground process; that doesn't
include actually extracting the process executable or current working
directory paths.
This was exacerbated by the mouse move events triggering a tab bar
recompute on every pixel of mouse movement.
This commit takes the following steps to resolve this:
* We now only re-compute the tab bar when the UI item is changed by
a mouse movement
* A simple single-item cache is now used on unix that allows the caller
to proceed quickly with stale-but-probably-still-mostly-accurate data
while queuing up an update to a background thread which can absorb
the latency.
The result of this is that hovering over several tabs in quick
succession no longer takes a noticeable length of time to render the
hover, but the consequence is that the contents of a given tab may be
stale by 300-400ms.
I think that trade-off is worth while.
We already have a similar trade-off on Windows, although we don't
yet do the updates in a different thread on Windows. Perhaps in
a follow up commit?
refs: https://github.com/wez/wezterm/issues/2991
We have to manually connect for this to work well across both
underlying libraries. libssh in particular doesn't support it
at all.
refs: https://github.com/wez/wezterm/issues/2893
