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
Adding unix part of std redirect code. Also modifying existing changes based on feedback from the initial PR.
More changes based on feedback from PR.
Non linux unix OS's forced to use dup2 instead of dup3
Avoiding disposal issues with fd.
Small bit of refactoring plus some more ammendments based on more PR feedback.
Non linux compile issue fix.
Adding return
Another fix
Another fix
More amendments
fmt correction
closes: https://github.com/wez/wezterm/pull/816
closes: https://github.com/wez/wezterm/pull/788
closes: https://github.com/wez/wezterm/issues/786
Need to use the subsecond microsecond value, rather than the total
microsecond value, otherwise `select(2)` will yield EINVAL.
The wezterm changes show where this error was bubbling up
and breaking the tls client code.
This avoids a deadlock waiting for the named pipe information to be
returned if we're probing during drop(). This does make the
OwnedHandle struct slightly larger on windows.
I didn't notice that windows has separate traits for raw sockets,
so blanket impls for things that returned RawHandle's were not
applying on windows in the same way that they were on unix systems.
