Re: async socket i/o [long]
Hi Michel, Please see below. --- Michel Andr� <michel.andre@swipnet.se> wrote:
Caleb Epstein wrote:
I disagree. On some platforms, there are multiple choices for the underlying event dispatching implementation. For example, on Linux you can use select, poll, or on newer kernels, epoll and kqueue. Even on Windows, there is more than one implementation that can be used (e.g. WaitForMultipleObjects, select (which I assume just wraps WFMO), and IO Completion Ports).
Some of these are semi-portable (e.g. select, poll) but the others are very specific to the platform. As a user I want the ability to choose the one that is most suitable to the task at hand.
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. 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. 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.
2. Would it be better perhaps to only provide behavior choices (sync, async, non-blocking) as part of the interface? [my thought is yes]
Not sure what you mean here. Connections may be either synchronous or asynchronous? This seems too limiting IMHO.
Aggreed you should be able to do eg synch/blocking write as a response to a asynch read, or do the handshaking/login synch and then go asynch.
I agree as well. This was just a misunderstanding of my question.
But I think most of the time the user will choos asynch or synch.
Indeed. Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
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
participants (2)
-
Don G -
Michel André