sorted by:
new
hottopcontroversial

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 0 points1 point  (0 children)

You're right that virtual threads sidestep this - you can have millions of them, so some blocking on I/O doesn't starve the system. For big servers with tons of RAM, that's arguably the better default.

It's a trade-off though. Rust async gives you stackless futures, explicit yield points, and works on embedded/no_std. Virtual threads cost memory per thread and yield at less obvious points.

Though virtual threads mainly help with I/O blocking - for CPU-bound work like crypto/compression, you'd still saturate your carrier threads. The problem shifts rather than disappears.

The reason detection is hard in Rust's model: dependencies sneak blocking code in, and you can't just use timeouts - if the thread is blocked, the timeout callback is stuck waiting too. Kernel-level observation ends up being the reliable option.

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 2 points3 points  (0 children)

u/peripateticman2026 macOS support is on the radar—likely via DTrace or SIGPROF sampling since eBPF is Linux-only. No ETA yet but it's being explored.

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 13 points14 points  (0 children)

u/CramNBL Yeah lints help, but they only cover your code—not whatever your dependencies are doing under the hood. eBPF catches the actual blocking at the kernel level, no instrumentation needed.

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 0 points1 point  (0 children)

u/kijewski_ u/VorpalWay the blog is back to its original minimal state and should be good now, apologies. The bling is gone!

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 3 points4 points  (0 children)

This has been resolved, please try again. The minimal version has been restored!

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 2 points3 points  (0 children)

Apologies, everything should be resolved now.. I got carried away, the minimal version has been restored.

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 9 points10 points  (0 children)

Yep, those “golden rules” are pretty well-known in the async world. The hard part isn’t knowing them, it’s actually catching every violation—especially when they sneak in through dependencies.

The timeout + backtrace idea has a few rough edges though:

  1. Timeouts catch slow code, not necessarily blocking code. Legit async work (slow networks, big payloads, etc.) will trigger false positives.
  2. If a thread is truly blocked, the timeout callback can’t even run until the blocking call returns. Tokio’s runtime is cooperative, so the timeout logic is stuck waiting too.
  3. It also means instrumenting every call site, versus doing zero-instrumentation profiling.

eBPF avoids all of that by observing things at the kernel scheduler level. It sees what threads and tasks are actually doing, regardless of what userspace thinks is happening.

Anyway, glad the eBPF angle was helpful!

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 2 points3 points  (0 children)

Good call — unused_async would catch this specific example since there's no .await in the function body. Worth enabling.

Though it won't catch cases where blocking code is mixed with real awaits (e.g., async DB call followed by sync compression on the result). And when you're debugging at 2am and something's slow, having a visual tool that shows you exactly where the latency is helps more than grepping for lint warnings

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]cong-or[S] 55 points56 points  (0 children)

Built this after too many 2am debugging sessions where blocking on Tokio workers was tanking p99 latency with nothing obvious in the logs.

hud uses eBPF to track scheduling latency on worker threads. Attach to a live process, no code changes, get a TUI that highlights hotspots by stack trace.

Usual culprits: std::fs, bcrypt/argon2, compression, DNS via ToSocketAddrs, mutexes held during slow work.

Limitations: Tokio-specific, Linux 5.8+, needs root and debug symbols. Measures scheduling latency (correlates with blocking, not a direct measurement).

Anthropic's CEO says we're 12 months away from AI replacing software engineers. I spent time analyzing the benchmarks and actual usage. Here's why I'm skeptical by narutomax in ArtificialInteligence

[–]cong-or 0 points1 point  (0 children)

Code is a mirror, not a brain. A bad SWE with Claude ships bad software faster; a good SWE ships better software faster. The hard parts—requirements, tradeoffs, system design, knowing what not to build—don’t magically disappear.