Fun article but the title is definitely overstating the huge amount of functionality lost if you replace Kafka. Immediately on my mind would be durability and broadcasting.
UNIX signals *do not* queue. If two or more signals with the same number are sent faster than the receiving thread handles them (due to the signal being blocked and/or the thread not being scheduled), all but the last will be lost irrevocably. There is no mechanism to prevent this.
We run a very simple filesystem based queue that processes around 1 billion events a day. Makes use of XFS for it's better handling of large numbers of files.
Corporate tried to push us to replace it with SQS and it could not keep up / costs with through the roof
"Yes, we built a message broker using nothing but UNIX signals and a bit of Ruby magic. Sure, it’s not production-ready, and you definitely shouldn’t use this in your next startup (please don’t), but that was never the point.
"The real takeaway here isn’t the broker itself: it’s understanding how the fundamentals work. We explored binary operations, UNIX signals, and IPC in a hands-on way that most people never bother with.
"We took something “useless” and made it work, just for fun. So next time someone asks you about message brokers, you can casually mention that you once built (or saw) one using just two signals. And if they look at you weird, well, that’s their problem. Now go build something equally useless and amazing. The world needs more hackers who experiment just for the fun of it."
I challenged ChatGPT the other day to design a bidirectional process interop in *nix and this was one of the suggestions. Until then I had only ever thought of pipes as unidirectional. I still thought it was bonkers. This looks like a neat prototype though.
I enjoyed reading the article and found it interesting. Had no prior interest in the topic but it was an entertaining read. Last time I used binary and calculated with it was in high school. Didn’t know about UNIX signals and now I understand how processes are terminating.
29 comments
[ 2.9 ms ] story [ 45.1 ms ] threadSignals are generally the slowest IPC method, unless you're doing something stupid with a different method.
If you choose to take this experiment further and go deeper, you will discover something even more fun: reentrancy.
... That, and how software interrupts work at the kernel level. Happy hunting!
EDIT: In anticipation of an eventual response, I just realized how condescending this sounds at first glance. I meant it in good faith.
The article is fine, but call it what it is: abusing the Unix signal system for shit and giggles. Nothing wrong with that.
A named pipe (like Postfix sendmail uses) seems slightly more sane.
https://ldpreload.com/blog/signalfd-is-useless
Corporate tried to push us to replace it with SQS and it could not keep up / costs with through the roof
"Yes, we built a message broker using nothing but UNIX signals and a bit of Ruby magic. Sure, it’s not production-ready, and you definitely shouldn’t use this in your next startup (please don’t), but that was never the point.
"The real takeaway here isn’t the broker itself: it’s understanding how the fundamentals work. We explored binary operations, UNIX signals, and IPC in a hands-on way that most people never bother with.
"We took something “useless” and made it work, just for fun. So next time someone asks you about message brokers, you can casually mention that you once built (or saw) one using just two signals. And if they look at you weird, well, that’s their problem. Now go build something equally useless and amazing. The world needs more hackers who experiment just for the fun of it."
[1]: https://man7.org/linux/man-pages/man3/sigqueue.3.html
I kind of hate this trend of making clickbait and then apologizing for it. I think its more annoying then just making clickbait.
Is it really that hard to just accurately title your blog posts?