Joshua Young

Allow sending SIGTERM to workers on timeout by schneems · Pull Request #157 · zombocom/rack-timeout When rack-timeout fires then it can put an application in a "bad" state. This is due to https://www.schneems.com/2017/02/21/the-oldest-bug-in-ruby-why-racktimeout-might-hose-your-server/....

> I believe `Rack::Timeout` does trigger a full process shutdown after killing a thread.

You need to opt in by enabling `term_on_timeout` (github.com/zombocom/rac...).

TIL 👀 Thanks!

Yes, just 3-12 bytes:
- github.com/puma/puma/bl...
- github.com/puma/puma/bl...

Good point, mmap + polling + small messages is probably less efficient than using pipes in this case. I'm still going to give it a go to scratch that itch 😊

I’m curious how Puma would perform with mmap instead of pipes, which it relies on heavily for IPC in cluster mode: github.com/puma/puma/bl....

I wrote (or rewrote) some gems to get better at Ruby C extensions and learn about these topics (CAS and mmap):
- github.com/joshuay03/at...
- github.com/joshuay03/mm...

I'm curious about this too. With YJIT in maintenance mode, bug fixes, UX improvements, etc., are probably welcome (a colleague recently found and fixed one). But with ZJIT being greenfield WIP, I'm not so sure. Completely understandable if that's the case though.

Young* 🙂

#rubykaigi | 🍯 Joshua Young Ruby friends, old and new, at #RubyKaigi 2025—another amazing edition of the largest and most prestigious Ruby conference. I love this community and this event, and hope to be back every year ❤️ Hug...

Had a blast at #RubyKaigi 2025!

www.linkedin.com/posts/joshua...

Great talk! Though my favorite is still the one you gave at RailsConf 2022.

As a noob OSS contributor and maintainer, I’ve learned a lot from your talks about the "duties" and "responsibilities" of both sides in OSS interactions—I’m trying to apply those principles in my own work as well.

#RubyKaigi late night with #RubyFriends !

It's not perfect but it does the job! Please let me know how you go if you give it a whirl.

So far I've tried it on three Rails monoliths of decent scale (including Buildkite's), and it gives me everything I need to profile requests in a multithreaded development environment - both Ruby and IO.

Add more ActiveSupport notification event markers by joshuay03 · Pull Request #119 · jhawthorn/vernier WIP New comprehensive list: # ActiveRecord sql.active_record instantiation.active_record start_transaction.active_record (added) transaction.active_record (added) # ActionController start_proces...

My current focus is production support.

I'm also hoping to add support for a few more useful AS notification events: github.com/jhawthorn/ve...

Then, I'd like to start thinking about adding some custom hooks to integrate with other gems.

With Dial, Vernier does all the heavy lifting, and viewing a request profile is just a click away. The hook into AS notifications is simple yet powerful, giving you a useful timeline of the events that matter.

I've included N+1 detection and VM stat diffs to complement these, open to more ideas.

GitHub - joshuay03/dial: A modern profiler for your Rails application A modern profiler for your Rails application. Contribute to joshuay03/dial development by creating an account on GitHub.

Announcing Dial, a Rails application profiler: github.com/joshuay03/dial

I've longed for a free tool that provides Datadog-like profiles, with accurate GVL and GC activity. Thanks to @jhawthorn.com's amazing work on Vernier, all I needed to do was integrate it with Rails and let it do its thing.

FYI the year on the post is 2022.

See you at RubyKaigi!

Makes sense, thank you for clarifying.

Sorry, I wasn't clear. If 8/10 threads are ~75% IO bound but with a reasonable spread e.g. query -> serialise, cache -> serialise etc., the CPU bound thread(s) will be interrupted quite often as they interleave. Is that something to be concerned about?

Interesting. Do you think that could introduce the opposite problem (CPU bound thread starvation in IO heavy workloads)?

I tried writing a basic Fiber scheduler based on this idea, but I haven't had the time to pick it back up (hit a roadblock with some segfaults with multiple threads). Took a while for it to occur to me that Threads might be able to work this way too...

github.com/joshuay03/fi...

Which would hopefully ease CPU bound thread monopolisation?

Obviously there'd be a bunch of other constraints e.g. need at least one other thread releasing the GVL pre-100ms, need to have a sensible lower bound/reasonable context switch overhead. Probably many more I haven't thought of...

Essentially CPU bound threads would have their priority gradually lowered the more complete slices they're granted:
- slice 1 100ms (priority 0)
- slice 2 100ms (priority 0)
- slice 3 50ms (priority -1) # arbitrary pick
...

Got slice calculation from: github.com/bensheldon/g...

I wonder what it would look like if Thread#priority was automatically set by the scheduler based on number of complete time slices utilised (100ms). I'm thinking Linux CFS-like scheduling using a red-black tree.

en.wikipedia.org/wiki/Complet... en.wikipedia.org/wiki/Red%E2%...

Random thought about Ruby thread scheduling fairness that I don't have sufficient knowledge of the VM to answer myself—without probably banging my head against a wall for a couple of days or weeks 🧵

#24 of 564 contributors to Rails last year—not too shabby for mostly working on OSS in my free time! Hoping to keep the momentum going in 2025 🚀

contributors.rubyonrails.org/contributors...

Happy Birthday!