Linus Färnstrand

@miquecg SOCKS based multihop is unrelated to the feature discussed in this issue. Sorry for dismissing you, but please send these not-directly-app-related questions to [email protected]. They will be way better...

Yes. Of course it will be in the UI :) But no ETA. We are working on the design.

Since `2022.1` WireGuard multihop is available in the **desktop** GUI. See this blog post: https://mullvad.net/en/blog/2022/3/10/wireguard-multihop-now-easy-available-app/ We have not yet started the Android implementation. But it should be relatively simple given...

I cannot give any ETA for when this will land on mobile. We currently work on more high priority features on both mobile platforms.

Yes, #757 does not solve the leak. I created a repository to easily test this and to see some differences: https://github.com/faern/leakruntime. This repository currently points to the `smol` branch of...

Yes the difference in what the macros expand to is shown in the `main.rs` file in that repo. The main difference being that `tokio` creates a `Runtime` blocks on it...

The very rare leak found in `#[tokio::test]` does exist for a normal sync test looking like this as well: ```rust #[test] fn just_sleep() { std::thread::sleep(std::time::Duration::from_millis(1)); } ``` So that one...

Since it's possible to interact with the global runtime via for example `async_std::task::spawn` I guess there could just as well be a `async_std::shutdown` function that cancels and frees all resources...

Does anyone have a branch ready with this change? To prove that it's possible. I think it's time to move ahead with this change. Would be great with these types...

> heapless version behind an alloc feature flag This sounds backwards. Anything named `alloc` should use the heap, not the other way around.