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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-12 22:55:00

Hi Michel,

Please see below.

--- Michel André <michel.andre_at_[hidden]> 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/