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

From: Scott Woods (scottw_at_[hidden])
Date: 2005-04-14 01:00:14

Hi Don and Michel,

----- Original Message -----
From: "Don G" <dongryphon_at_[hidden]>
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?