Will it block? — 2024-02-07 Will this function block? fn work(x: u64, y: u64) -> u64 { x + y } How about this function? fn work(x: u32) -> u32 { let mut prev = 0; let mut curr = 1; for _ in 0..x { let next = prev + curr; prev = curr; curr = next; } curr } Or this one? use sha256::digest; fn work(input: &str) -> String { digest(input) } Will this function block? use std::{thread, time::Duration}; f
Four years ago today, the Rust async/await feature was released in version 1.39.0. The announcement post says that “this work has been a long time in development – the key ideas for zero-cost futures, for example, were first proposed by Aaron Turon and Alex Crichton in 2016”. It’s now been longer since the release of async/await than the time between the first design work that underlies async/awai
Recently, I found myself returning to a compelling series of blog posts titled Zero-cost futures in Rust by Aaron Turon about what would become the foundation of Rust's async ecosystem and the Tokio runtime. This series stands as a cornerstone in writings about Rust. People like Aaron are the reason why I wanted to be part of the Rust community in the first place. While 2016 evokes nostalgic memor
There is a common sentiment I’ve seen over and over in the Rust community that I think is ignorant at best and harmful at worst. This blogpost is largely a response to this post by Matt Kline, but I’ve seen this kind of sentiment all over the Rust community. I’ve found that, in almost every case where async/await is mentioned, at least one person says this. It always gets on my nerves a little bit
But to get at whatever the hell I mean by that, we need to talk about why async Rust exists in the first place. Let’s talk about: Modern Concurrency: They’re Green, They’re Mean, & They Ate My Machine Suppose we want our code to go fast. We have two big problems to solve: We want to use the whole computer. Code runs on CPUs, and in 2023, even my phone has eight of the damn things. If I want to use
I've found that one of the best ways to understand a new concept is to start from the very beginning. Start from a place where it doesn't exist yet and recreate it yourself, learning in the process not just how it works, but why it was designed the way it was. This isn't a practical guide to async, but hopefully some of the background knowledge it covers will help you think about asynchronous prob
2023-06-30 async fn is an inversion of control Hand-rolling an explicit state machine Explicit state machines mean your caller has control Writing state machines with async fn await is a composition operator Summary (This is a section of the lilos intro guide that people seemed to like, so to increase its visibility, I’m lifting it up into its own post and expanding it a bit. I hope this is a usef
はじめに 登壇版 Taskの本質 C# のイテレータ async/await Compiler Transform ExecutionContext builder.Start() の重要性 IAsyncStateMachine.MoveNext おわりに はじめに C#er は呼吸するように使っている async/await。 そんな async/await について、先日 Stephen Toub 氏 (.NET の中の人。中心人物の一人。) が How Async/Await Really Works in C# という非常に面白い記事を投稿していました。 この記事では Stephen 氏の記事をベースに、C# において async/await は実際どうやって動いてるの?というお話をしていきます。 以前に C#での非同期メソッドの分析。 という翻訳記事を書いたのですが、元になった記
お願い 「C10K 問題とは何か」がわかる方は是非 Issue や Twitter などで教えてください。 追記: 自分の立場 1req ごとに 1 native thread を割り当てていたら、クライアントの数が増えれば増えるほど負荷が高まるのは当然だ。ただハードウェアの性能的に余裕があっても性能が劣化することがあり、それを C10K 問題と呼ぶ。C10K 問題は fd, pid の枯渇、スレッドを固定長サイズで確保することによるメモリの無駄遣い、コンテキストスイッチコストを含む。これを解決する方法が 1req ごとに 1 native thread を割り当てない技術で、シングルスレッド+イベントループ+IO 多重化といったテクニックや M:N モデルにつながる。 追記: @naoya_ito さんに解説してもらった当時の歴史的背景 https://twitter.com/naoya
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ?」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
Several weeks ago, the .NET Blog featured a post What is .NET, and why should you choose it?. It provided a high-level overview of the platform, summarizing various components and design decisions, and promising more in-depth posts on the covered areas. This post is the first such follow-up, deep-diving into the history leading to, the design decisions behind, and implementation details of async/a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く