Hacker News Reader

Comment by paulsutter | Hacker News Reader

If you want to write any complicated concurrent code, the simplest and best way is one long polling loop state machine. You might use a thread to call a blocking API, but the majority of the logic should be in a polling loop.

I used to love chained callbacks when I was 16, and later I thought threads were the greatest, and I've written a bunch of device drivers that operate at different IPLs.

But 20 years ago a cofounder made me realize that a long polling loop is easier and faster to write, and much easier to understand than threads. That insight has made countless projects simpler and easier and I recommend considering it. You may be surprised, as I was.

View on HN

Ideally, you don't have blocking APIs at all. There isn't any reason nowadays. Every blocking API in your system is there for historic reasons (ie it's >20 years old) or because somebody made a terrible design decision in the last 20 years.

I am obviously referring to operations that do actual IO or wait for work on other threads only.

I don't know that I agree. Blocking logic is far easier to understand, as it lets you ignore partial operations. It also lets you specify, in a more direct manner, where data is buffered.

One would argue the best approach is non-blocking written in a blocking fashion for clarity. async/await instead of Promises and Thens.

Most languages have this now. For the ones that don’t, they have pointers, so writing a thread pool event loop is trivial.

Maybe, though that is a bit of having your cake and eating it, too.

I am very open to the argument that you should be able to do both. I'm even open to the idea that this is closer to preemptive multitasking. Where the manual version basically lost, and it is taking time for some of us to realize it. :)

> Ideally, you don't have blocking APIs at all. There isn't any reason nowadays.

If you're working with the JVM, you can write simpler blocking code that is also performant through virtual threads.

What do you mean by a long polling state machine? Is it just a state machine that gets fed via long polling http requests?

No, he means a run loop which polls for events, often by using poll() or select(), but it could also just be sleep() and then a SELECT statement.

Then it contains logic to handle events.

Ah thanks. Didn't hear 'long polling' in that context yet.

Half of what you're describing is an async event loop, but it isn't strictly tied to a state machine.

Reply on news.ycombinator.com