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
Inspecting the wezterm process with `lsof -p`, before and after closing
a pane with `CloseCurrentPane`, the same number of unix domain sockets
are open, which is bad.
This commit tries a bit harder to clean things up: if we got a process
exit condition we now remember that we had it, and, while processing
the IO for that channel, if we have no data for stdout or stderr
(respectively) and the channel exited, we close our end of the
socketpair to encourage EOF to be detected on the other end.
This is sufficient to restore the number of open files to the same
number wezterm had opened prior to opening that pane.
@chipsenkbeil: this might possibly be a factor in the issue you
reported, but I haven't had time to really dig into that yet!
refs: https://github.com/wez/wezterm/issues/2466
refs: https://github.com/wez/wezterm/issues/2456
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
We need to notice when all of the streams associated with a channel are
closed and remove the channel from the set that we're polling in the
main loop, to avoid continually polling the closed descriptors.
Additionally, if the Session has been dropped, we know that we cannot
be asked to create any new channels, so if there are no more channels
then we can and should exit that dispatch loop and allow the resources
to be cleaned up.
refs: https://github.com/wez/wezterm/issues/1993#issuecomment-1130539934
Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
This helper extracts the concrete set of hosts and their configurations
from the ssh config, and arranges to reload the wezterm config if they
are changed.
This is useful when constructing ssh domain configs.
refs: https://github.com/wez/wezterm/discussions/1731
* Re-export portable_pty::PtySize as it is available in public API
* Re-export portable_pty::{MasterPty, ChildKiller} as those are both implemented by public structs from wezterm-ssh
It looks like the debian 9 test failures with libssh are the
same underlying issue as https://github.com/wez/wezterm/issues/1262
Poking around in the debug output, and then spelunking through the code,
we can use the `pubkeyacceptedtypes` ssh config option to add the key
type to the list of keys. This doesn't appear to be a documented
option in the current versions of openssh.
I'm not 100% sure that this is right, but it's worth a shot.
```
thread 'e2e::sftp::canonicalize_should_either_return_resolved_path_or_error_if_missing' panicked at 'Unexpected result from canonicalize: Err(LibSsh(Sftp(SftpError(2))))', wezterm-ssh/tests/e2e/sftp.rs:615:14
```
We can't currently match that error because the LibSsh SftError(x) error
code is private.
Route logging via the `log` crate because on Windows there is
no stderr visible to libssh.
libssh will override any explicitly set options when it parses
the config file, so we need to apply those after we've loaded it.
A recent cargo update caused openssl-sys to do a minor semver update
from 0.9.71 -> 0.9.72, but that release downgraded from openssl 3
to openssl 1 to resolve a performance regression:
<https://github.com/sfackler/rust-openssl/pull/1578>
That in turn caused libssh to fail to build because the ENGINE
feature required by libssh isn't compiled in in openssl-src 1
crate when vendoring on windows.
For now, my libssh git repo is constrained to openssl-sys 0.9.71,
and we're pointing to that from the wezterm repo.
