Comparison of Rust async and Linux thread context switch time and memory use

Re:Comparison of Rust async and Linux thread context switch ... by lxpz on Friday February 12, 2021 @08:15AM (#26113261)

That .NET syntax using Task.WhenAll seems quite bad, which might be part of the reason why not many people bother (disclaimer: I don't do C# or ASP.NET). In Rust it would be:

    let p, c, m = join!(
        GetUserPermission(username),
        GetServerConfig(),
        GetMessageOftheDay()
    );

(you don't even have to write await when using the join macro)

With such simple syntax available it seems obvious to me that one would want to use it as often as possible, and it's also much simpler (and probably cheaper) than dispatching those three tasks to a thread pool.

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by moocowtruck on Friday February 12, 2021 @08:52AM (#26113611)

var r = await Task.Whenall(f1,f2,f3); Console.WriteLine($"{r[0]}, {r[1]}, {r[2]}");

f1,f2,f3 are all async fn's, that is all you have to do

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by Serow225 on Friday February 12, 2021 @09:59AM (#26114292)

yeah, the original example is showing the unwieldy version of the syntax.

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by jiggawatts on Friday February 12, 2021 @07:26PM (#26120265)

The original example by me did not assume that asynchronous functions all return the same result type.

Mist opportunities for concurrency are between unrelated tasks (because related tasks often dependencies between them). Unrelated tasks tend to have unrelated return types.

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by concretemarble on Sunday February 14, 2021 @09:04PM (#26138248)

When tasks are unrelated, you also likely don't need them all at the same time for the next stage of pipeline. You can simply await it when you need it.

  var p_t = GetUserPermission(username);
  var c_t = GetServerConfig();
  var m_t = GetMessageOfTheDay();
  function_to_call1(await p_t, await c_t);
  function_to_call2(await m_t);

This does not look any more complicated than a non-async function. Not sure how this example justifies your claims.

Besides, even if your example is valid, the usage of Task.WhenAll has nothing to do with your claims either. The use of async/await is majorly for scalability. Being able to make several network calls concurrently is not the major concern. Even if you await at each async call, you still achieve better scalability because threads won't be blocked for async calls and can work on something else.

[ Parent | on HN ]