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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-14 07:45:49

Hi Scott,

When I implemented this at work, the sync stuff did indeed rely on
the internal async mechanism. It turned out "better" not to pass
function objects about for the synchronous case, though it would
work. So, I guess it is partly a performance thing as well as a
convenience thing to allow mixing sync/async without mixing layers.

The async flow (aka, "function queue") is something I would like to
revisit soon. A key concept of my proposal (which I should post to
the sandbox) is cancel. This complicates the use case, but I don't
see a way out of it.

Best,
Don

--- Scott Woods wrote:
> 
> Hi Don and Michel,
> 
> 
> ----- Original Message -----
> From: "Don G"
> To: <boost_at_[hidden]>
> Sent: Thursday, April 14, 2005 4:07 PM
> Subject: [boost] Re: async socket i/o [long]
> 
> 
> > Hi Michel,
> >
> > > Ok the reason I expose it is for the possibility
> > > to write single threaded reactive servers.
> >
> > I have written such using the library I proposed. The missing
> > ingredient is a function queue mechanism. I posted one to the
> list a
> > couple weeks ago, but feel that it is not technically a
> networking
> > thing. Of course, the network layer could be coupled to it in
> some
> > key places which would make things simpler to use.
> >
> 
> [snip long useful text]
> 
> I agree and nicely written :-) At least that stuff feels better. I
> have to
> admit
> I'm still tangled up with the broader scope. Wondered if this might
> clarify
> things;
> 
> [4] boost
> --|-------------------serialization-------------------------|
> [3] boost --|-----------|---------------|- sync file --|-- sync
> socket -|
> [2] boost --|-----------|---------------|- async file -|- async
> socket -|--------------
> [1] boost --|- sync file -|- sync socket
> -|-----------------------------|-
> async flow -
> [0] system -|- sync file -|- sync socket -|- async file -|- async
> socket -|-
> async flow -
> 
> Level [0] shows the platform APIs. The repeated names at levels [1]
> and [2]
> are the
> Boost interface to the same names at system level; the boost
> versions are
> platform
> independent. The boost async libraries for file and socket I/O are
> bumped up
> to
> level [2] to highlight the need for a generic "async flow" library.
> A means
> of passing
> control from one dis-joint code fragment to another.
> 
> Sync file and sync socket appear again on level [3] as that
> behaviour may be
> re-implemented over the async level.
> 
> Serialization is shown at the top for obvious reasons.
> 
> I suppose for any given platform there may be holes, e.g. an old
> MacOS may
> not
> support async file. According to this diagram at least, sync file
> and sync
> socket are
> optionally implementable as either a layer over the platform API or
> as
> something
> that makes use of the boost async file and async socket.
> 
> While this might be all a bit pie-in-the-sky, if sync file and sync
> socket
> can be
> implemented over a platform independent interface, the only time
> you wouldnt
> do so would be when the platform has no async support? Or for
> absolute best
> speed as you described in your text?

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