| |||||||||||
Interest in asynchronous I/OInterest in asynchronous I/OPosted Jul 25, 2003 17:11 UTC (Fri) by GreyWizard (subscriber, #1026)In reply to: Interest in asynchronous I/O by larryr Parent article: 2003 Kernel Summit: Asynchronous I/O Could you (or someone else) explain in more technical detail what the benefit of asynchronous I/O is? Why is it better than a select(2) loop?
(Log in to post comments)
Interest in asynchronous I/O Posted Jul 31, 2003 12:52 UTC (Thu) by mwilck (guest, #1966) [Link] The asynchronous IO programming paradigm is more intuitive. No select loop needed. You just launch a number of AIO requests, do whatever else you want, and if you need the data you wait for the AIO completion. Moreover, between the aio submission and its completion the associated buffers belong to the kernel. That is why 0-copy basically only works this way.
Interest in asynchronous I/O Posted Jul 31, 2003 16:39 UTC (Thu) by johnchx (guest, #4262) [Link] One problem with select() is that it scales poorly to very large numbers of file descriptors. It works fine with a couple of dozen, but when you're handling 10,000 + network connections, the work of simply passing the file descriptors to and from the system call and the work (when select() returns) of figuring out which of the 10,000 descriptors has become ready can consume a significant fraction of the available cpu cycles.There's a paper on this at: http://citeseer.nj.nec.com/cache/papers/.../banga99scalable.pdf
Interest in asynchronous I/O Posted Nov 26, 2003 10:09 UTC (Wed) by yzhuang (guest, #3178) [Link] epoll has broken the bottleneck very well. it is much more scalible
|
|||||||||||