3 ms·
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 year
by jupp0r 3y ago
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.
- taeric 3y agoI 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.
- reactordev 3y agoOne 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.
- taeric 3y agoMaybe, 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. :)
- okeuro49 3y ago> 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.