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).
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).
From that perspective, the Windows model is actually easier to grasp
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.