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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-12 10:42:59

Hi Caleb,

I'll try to address both topics since they are mushed together (as
in, I'm not sure they are independent questions after all<g>).

> Not sure what you mean here. Connections may be either
> synchronous or asynchronous? This seems too limiting IMHO.

I meant "the connection process", not the whole object. :) All
activities have sync/async forms and I/O methods also have
non-blocking. See the sandbox, network.zip/network.html for details.

http://boost-sandbox.sourceforge.net/vault

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

I'm not sure I understand "suitable to the task at hand". By this do
you mean: "I'm writing a simple app that makes a single stream
connection" vs. "I'm writing a server that accepts 10,000
connections"? That kind of task? If so, this doesn't sound like an
argument for epoll vs. select vs. kqueue. It rather sounds like a
desire for the interface to make simple things simple and hard things
possible.

In other words, why should one care "how" operations are
accomplished? It sounds akin to the user selecting Windows API
CreateFile flags when opening an ifstream. As soon as we start down
this path, the user must code to platform-specific behaviors and
interfaces. Exposing such details, IMHO, is a big problem for the
user for no benefit that I can see (yet? <g>).

I believe that instead of chosing between say epoll and kqueue, the
user should chose to block or get callbacks, etc.. I would suggest
that for any given platform, there is a best/good_enough choice that
would shield the user from these non-portable concerns. If the
mechanism seems important, perhaps being involved in the
implementation of the interface for a given platform would address
these concerns?

>From my perspective, understanding network concepts is hard enough
for novices. I really believe that we would be best served by a
portable, clean abstraction of these primitives that provides
synchronous and asynchronous forms of all time consuming operations,
and non-blocking I/O. Other concerns, IMHO, are implementation
details.

Best regards,
Don

--- Caleb Epstein <caleb.epstein_at_[hidden]> 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.
> 
>> 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.
> 
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/