3 ms·
Unfortunately most of what you want to do with await/async is IO based, the IO model matters a lot if you want it to be scalable. Without kernel support trying
by jpgvm 12y ago
Unfortunately most of what you want to do with await/async is IO based, the IO model matters a lot if you want it to be scalable. Without kernel support trying to build a completion based API is not very performant. Trying to emulate it in a library proved painful, especially when trying to do IO on files.
- thristian 12y agoI'm not sure that's true. The same kind of mechanical transformation that gives await/async also leads to Python-style generator functions, and I wind up using them all the time for all kinds of iteration tasks, not just I/O (or at least, not just async I/O).
- barrkel 12y agoYou're conflating two distinct concepts. Certainly, code rewriting to support continuation is a factor in both C#-style await and generator functions, but they are not the same thing. Much of the motivation behind async I/O is to reduce the number of active threads blocked on I/O. Blocked threads means stack space consumed, kernel transitions, and potentially CPU contention if too many threads become runnable at once, and then start fighting over mutexes or cache. In this way of looking at the world, you don't want to block for any I/O. That's what the GP is getting at.