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

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-12 12:57:01

Caleb Epstein wrote:
> On Apr 12, 2005 12:17 AM, Don G <dongryphon_at_[hidden]> wrote:
> 
> 
>>1. Should the network library provide different choices of
>>implementation to the user? For the most part, the platform will
>>dictate the available solutions, so having the user decide would make
>>their code non-portable. [my thought so far is no]
> 
> 
> 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.

>>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. 
But I think most of the time the user will choos asynch or synch.

/Michel