2 ms·
This was my thought too. I've been struggling with the concept of "if you don't have anything nice to say, don't say anything at all" lately, because I've been
by zackmorris 4y ago
This was my thought too. I've been struggling with the concept of "if you don't have anything nice to say, don't say anything at all" lately, because I've been programming too long and just see poison pills and better alternatives everywhere I look.
But I believe that async is an anti-pattern. From the article:
* When an nginx worker is blocked, it cannot service other requests
* Solutions to prevent nginx from blocking like aio or thread pools scale poorly
Nothing against nginx (I use it all the time, it's great) but I probably would have used a synchronous blocking approach. The bottleneck there would be artificial limits on stuff like I/O and the number of available sockets or processes.
So.. why isn't anyone addressing these contrived limits of sync blocking I/O at a fundamental level? We pretend that context switching overhead is real, but it's not. It's an artifact of poorly written kernels from 30+ years ago (especially in Windows) where too many registers and too much thread state must be saved while swapping threads. We're basically all working around the fact that the big players have traditionally dragged their feet on refactoring that latency.
And that some of the more performant approaches like atomic operations using compare and swap (CAS) on thread-safe queues beat locks/mutexes/semaphores. And that content-addressable memory with multiple busses or even network storage beats vertical scaling optimizations.
So I dunno, once again this feels like kind of a drink-the-kool-aid article. If we had a better sync blocking foundation, then a simple blocking shell script could serve video and this whole PDF basically goes away. Rinse, repeat with most web programming too, where miles-long async code becomes a single deterministic blocking function that anyone can understand.
I'm kind of reaching the point where I expect more from big companies to fix the actual root causes that force these async workarounds. I kind of gave up on stuff like that over the last 10 years, so am behind the times on improvements to sync blocking kernel code. I'd love to hear if anyone knows of an OS that excels at that.
- 0x457 4y agoSlide 25 shows benchmark between "old" sendfile and "new" sendfile: https://www.slideshare.net/facepalmtarbz2/new-sendfile-in-english https://www.slideshare.net/facepalmtarbz2/new-sendfile-in-en... > but I probably would have used a synchronous blocking approach. Well, send a patch, then.
- wmf 4y agoI probably would have used a synchronous blocking approach Then Varnish is probably more your style. (A discussion between phk and drewg would be fascinating to watch.) We pretend that context switching overhead is real, but it's not. This sounds crackpot to be honest. Linux has put a lot of effort into optimizing context switching (that's why they have NPTL instead of M:N) and I assume FreeBSD has as well. ...this whole PDF basically goes away Sync vs. async doesn't solve any of the NUMA or TLS issues that this whole PDF is about.
- toast0 4y agoIf you rely on blocking I/O, you've got to deal with blocked processes as i/o isn't instant. You can deal with that by having lots of threads or processes doing the work, but coordinating many threads can be difficult. With async sendfile, you let the kernel manage all of this without needing userspace to do anything, and the kernel is well organized to manage pushing data to the right place when disk i/o completes. If you just want to write code in blocking style, check out Erlang, but know that under the hood it massages most of the blocking into aggregated select/kqueue/epoll/etc calls.