Don G wrote:
But reasonable and efficient defaults should be used so you would not have to choose. Eg iocp on windows and kqueue on linux.
There should be some measurement made to show IOCP as better than select (it might be, but by how much?). The reasons to prefer select to IOCP are significant: select is much more portable (meaning no extra work for Windows); IOCP is NT only (no 9x/Me). So, if IOCP just blows the doors off select, it might be one of these places where a user needs to chose an implementation for a single platform.
IOCP provides the most scalable way to do I/O on Windows NT and later and it will blow the sock off just about anything it minimizes context switching by activaiting threads in FIFO order keeping a single thread hot, and blocks dequeing completions if there are more runnable threads on the port than cpus in the machine. Any serious server application should consider using it. But having a solid portable select based mechanism to fall back on could be used on any platform (supporting BSD sockets at least). Anyways maybe we should settle for the requirements, before we decide the details, but preferably I think the interface shouldn't rule out an IOCP based implementation. And there seems to be a lot of different opinions on what kind of servers and scalability requirements the interface should provide. From simple blocking to full blown asynch with best implentation on any given plattform.
An important note: the _only_ reason is to trade backwards compatibility with old an OS family for performance. There should be _no_ difference in the interface and behavior.
Preferably not and therefore it's important to validate the implementability of the interface for iocp.
I don't see any reason this would need to be a run-time choice, though it could be in the approach I am proposing. It would just be a different concrete network object.
Agreed. /Michel