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.

https://ldpreload.com/blog/signalfd-is-useless

RT signals do get queued... that is one of the major differences (and yes, the essay is not using them, so your point stands as it is written, but using RT signals is a mechanism to prevent it).

https://davmac.org/davpage/linux/rtsignals.html

Naively asking: what prevents RT Unix/Linux from being used in place of non-RT mainstream versions? Seems like a superset.

RT signals are an extended API of POSIX you don't need actual RT Linux to use them.

Are they guaranteed to be delivered in order?

Yes as long as you use sigqueue with SA_SIGINFO

Come to think of it, I think the original idea can be salvaged with an acknowledgment signal. Send bit, wait for acknowledgment, send next bit or retransmit accordingly. Actually you would need a handshake before each bit.

That's easily solved, just create a queue for your signals.

It is waiting for NULL! :)

Before y'all go nuts with the criticisms...

"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."

Unfortunately I bet that 90% won't even reach at that part and just ragebait based on the title. The golden rule of modern age is always do the disclaimer as soon as possible.

Or you could skip the rage bait title entirely?

The one they changed the HN title to be… basically remove the “You don’t need Kafka” bit.

Oh I never sad the original, that's why I was confused. Thanks.

Maybe, but I know Leandro, it was more a joke than anything else. People just don't chill, the post is cool

I'm truly curious to know why would this be rude, seriously. Maybe it's a cultural mismatch.

For me ragebait and rudeness are things like: "X sucks, use Y", "If you aren't doing W you're losing money", etc.

He never said that Kafka sucks, nor anything related, obviously you can't replace kafka with only two signals. I'm asking with all politeness as possible, I just wanna understand what other people consider improper behavior

Nah, I wouldn't say this is rude or even a ragebait title. It's completely accurate and to the point...

That's fine, but then you shouldn't be surprised and complain when people respond to the rage bait.

The later the disclaimer, the funnier.

This has nothing to do with Kafka and it's not not really a functioning message queue except for theoretically speaking.

The article is fine, but call it what it is: abusing the Unix signal system for shit and giggles. Nothing wrong with that.

This was a really fun article and many in the comments seem to have forgotten you're allowed to have fun with the computer.

This is awesome. Does POSIX guarantee the order of signal delivery? And I'm dying to see what the bandwidth / throughput of this channel is...

I don't know if POSIX has a position on signal order. But I'm pretty sure it allows signals to be coallesced... if a process is sent the same signal several times before the handler is invoked, it's in spec to only invoke it once.

Real-time signals have guaranteed order: first by number (lowest first, i.e. `SIGRTMIN`), then by the order in which they are sent.

Signals are generally the slowest IPC method, unless you're doing something stupid with a different method.

Answering both of my questions, from the post:

  sleep 0.001 # Delay to allow the receiver to process the signal

For standard signals--no, but for real-time signals, yes. The latter are still a portability issue, though.

This is the kind of article that deserves to be posted on April 1st, preferably with an accompanying RFC published at the IETF.

Why use signals when POSIX defines a complete message queue interface: https://www.opensourceforu.com/2023/06/a-deep-dive-into-posi...

Wow, I didn't know! I will work on replacing my Kafka cluster handling 10 million msg/sec with this right away!

you can literally just attach data[1] to signals... you don't need to do this.

[1]: https://man7.org/linux/man-pages/man3/sigqueue.3.html

Such titles should be flagged and banned to protect the innocent.

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

How does it work? Can you have multiple workers on the same payload? Do you archive the events afterwards?

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.

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 liked a lot your article, hacking with Unix signals is impressive, and was faster than I expected. I would have expected signals to be slower.

Initially I assumed that the author was about to use something like shared memory for bulk transfer. Boy I was totally wrong...

You have problem with too much traffic that your server can't handle. You add a queue. Now you have 2 problems :)

I hope this is a joke / hack.

A named pipe (like Postfix sendmail uses) seems slightly more sane.

Yeah, there are a lot of more elegant, simple and reliable ways to do that.

Glad you had fun doing this!

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.

Great article for learning UNIX Signal

Can those two Unix signals run Doom?

One of my favorite things that happens on the internet is when it is clear as glass when someone didn't read the article.

You nailed it!

Obligatory: Kafka is a log, not a message queue (although it turns out there's a lot of overlap)

I read the article. I think it is accurate enough.

Attention is the new oil.

Click bait