On Mon, Nov 5, 2012 at 6:19 AM, Sturla Molden <sturla@molden.no> wrote:
My main problem with IOCP is that they provide the "wrong" signal. They tell us when I/O is completed. But then the work is already done, and how did we know when to start?
The asynch i/o in select, poll, epoll, kqueue, /dev/poll, etc. do the opposite. They inform us when to start an i/o task, which makes more sense to me at least.
Typically, programs that use IOCP must invent their own means of signalling "i/o ready to start", which might kill any advantage of using IOCPs over simpler means (e.g. blocking i/o).
From that perspective, the Windows model is actually easier to grasp
This sounds like you are thoroughly used to the UNIX way and don't appreciate how odd that feels to someone first learning about it (after having used blocking I/O, perhaps in threads for years). than the UNIX model, because it is more similar to the synchronous model: in the synchronous model, you say e.g. "fetch the next 32 bytes"; in the async model you say, "start fetching the next 32 bytes and tell me when you've got them". Whereas in the select()-based model, you have to change your code to say "tell me when I can fetch some more bytes without blocking" and when you are told you have to fetch *some* bytes" but you may not get all 32 bytes, and it is even possible that the signal was an outright lie, so you have to build a loop around this until you actually have gotten 32 bytes. Same if instead of 32 bytes you want the next line -- select() and friends don't tell you whether you can read a whole line, just when at least one more byte is ready. So it's all a matter of perspective, and there is nothing "wrong" with IOCP. Note, I don't think there is anything wrong with the select() model either -- they're just different but equally valid models of the world, that cause you to structure your code vastly different. Like wave vs. particle, almost. -- --Guido van Rossum (python.org/~guido)