JP Camara
banner
jpcamara.com
JP Camara
@jpcamara.com
Principal software engineer @Wealthbox.
Husband/Father. Health, travel, tech and Ruby enthusiast.
Tech blog at https://jpcamara.com
Jokes at https://logicalconclusionscomic.com
Also very curious! I was big into warp for a while, but a) they literally still don't support full terminal history and cap at 20k lines and b) feels like they're getting further and further from prioritizing the actual terminal part
i'm back on iterm2 again, but i'd love a better tool
November 10, 2025 at 1:25 PM
ok nice to know you are still human 😂😂😂!
November 2, 2025 at 7:41 PM
Amazing, thanks for putting a name to it @byroot.bsky.social ! I'm gonna dig into this more
November 2, 2025 at 7:08 PM
"Today I ran Brussels half marathon and it was 21.1km of pure joy!"

I have never heard a marathon described as "pure joy" 😂 It must have truly been something special!
November 2, 2025 at 7:04 PM
Thanks for the reference! I'm gonna check this out more. Zeitwerk is something I think would be super interesting to read through - I bet there's some unique stuff you've had to do in there
November 2, 2025 at 7:03 PM
4) "When good threads go bad" coming soon!

Dan shows how jobs are executed in the `process` method, which has this hefty section utilizing `handle_interrupt`. He does a great job describing how it works, and my next article will dig deeper into if you're interested!

11/11 🧵
November 2, 2025 at 2:27 AM
If you read my article on ruby thread interrupts and bitmasks, this will be very familiar! jpcamara.com/2025/10/22/b...

I asked koichi if signals were the inspiration, and he confirmed it. It was fun to see the connection and what can be an inspiration for central language apis!

10/11 🧵
November 2, 2025 at 2:27 AM
3) The design of Ruby thread interrupts seem heavily influenced by linux signals

When referring to the linux signal docs, I noticed a startling resemblance - it included `raise` and `kill` functions, a list of pending signals, and a way to block signals using bitmasks with pthread_sigmask

9/11 🧵
November 2, 2025 at 2:27 AM
`compare_by_identity` sets the hash to compare keys by their reference instead of their value. Not day-to-day useful but a fascinating option, and utilized nicely in Sidekiq

8/11 🧵
November 2, 2025 at 2:27 AM
You can change the default return value of a hash by using `default=` on the hash. docs.ruby-lang.org/en/3.4/Hash..... Now instead of nil, you'll return whatever `default` you provided! Very handy.

7/11 🧵
November 2, 2025 at 2:27 AM
`handle_signal` can do what it wants! No reentrancy requirements! No special requirements at all in fact - we're back in the regular flow of our program! Super clever.

2) Two weird hash methods big Hash doesn't want you to know...

6/11 🧵
November 2, 2025 at 2:27 AM
Meanwhile, the main loop for sidekiq is always waiting on the io reader, calling a blocking method, `wait_readable` in the while loop. Signal received -> write the signal -> wait_readable returns truthy -> while loop runs and calls `handle_signal` with the signal read

5/11 🧵
November 2, 2025 at 2:27 AM
The full reasons for that are explained in docs.ruby-lang.org/en/3.4/signa..., and have to do with a concept called "reentrancy".

But mike bypasses all of that by using using IO.pipe. The io writer is safe to write to in the trap, so that's all it does, it writes the signal.

4/11 🧵
signals - Documentation for Ruby 3.4
signals: Caveats for implementing Signal. trap callbacks As with implementing signal handlers in C or most other languages, all code passed to Signal.
docs.ruby-lang.org
November 2, 2025 at 2:27 AM
1) @mike.contribsys.com you clever devil, that Signal.trap approach is ingenious!

In my post on thread interrupts, I mentioned that you cannot use rails.logger inside of a signal.trap: bit.ly/43c23Ym. Similarly, you cannot use the Sidekiq logger in trap, which is inconvenient.

3/11 🧵
November 2, 2025 at 2:27 AM
1) @mike.contribsys.com is a exceedingly clever!
2) I've used Ruby for 12+ years now, and I learned new Hash methods from this article
3) The design of Ruby thread interrupts seem heavily influenced by linux signals
4) My next article "when good threads go bad" will pair nicely with this!

2/11 🧵
November 2, 2025 at 2:27 AM
Reposted by JP Camara
3️⃣ @jpcamara published a new article about Bitmasks, Threads and Interrupts: Concurrent, colorless Ruby

jpcamara.com/2025/10/22/...
October 29, 2025 at 4:00 PM
I LITERALLY had that same thought hahahahaha. I thought "damn that is the one environment where they'd be 100% chill with that shirt, nice" 🤣
October 27, 2025 at 5:20 PM
Congrats cody!
October 27, 2025 at 4:52 PM
I completely appreciate that it works, and i'm sure works well for the core team in particular. But for someone who does not interact with it regularly, you land there and immediately think "is this really it?"
October 27, 2025 at 3:41 PM
As someone who has contributed to CRuby here and there, I will say that bugs.ruby-lang.org does not feel friendly to interact with. I'd really love to go into a system that doesn't feel like something i'd have used 15 years ago. Also can we change "edit" to "reply" please 💀
Ruby Issue Tracking System
Redmine
bugs.ruby-lang.org
October 27, 2025 at 3:41 PM