From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-13 15:03:25
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk