[boost] Re: async socket i/o [long]

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 
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