William Ahern wrote:
There are many ways to do AIO. I know of none that don't use threads, either kernel threads or user process threads. Now, the threads could be "light weight", but there's still a calling context that blocks on an operation. But no implementation is equivalent to, say, how the socket subsystem [state machines] work, where the only state that needs to be maintained is a queue of waiting objects (where object != thread). To put it simply, all the AIO implementations use too much memory and do too much book keeping (like thread scheduling) than strictly necessary, because kernels don't have a way to to "poll" on VM pages (as opposed to polling on disk interrupts, which you can accomplish when do doing direct I/O).
Direct I/O sounds sufficient for me personally (but not for everyone). This discussion sounds fresh and rational to me. A mechanism to "poll" on VM pages is very useful for database engines to deal mmap-ed files in more reliable way, however I don't completely understand why it is necessary to implement AIO on cached files. Could you please explain this?
-- Regards, Valery Kholodkov _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
