Re: [boost] Re: Asynchronous I/O

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-31 00:20:24

Hi Don,

Its been a while (Easter holiday/motorbikes/surfing). Lots of messages to
chew through after a good break.

There seems to be a lot of technical detail; platform specifics and
implementation. All good but its really easy (for me) to lose sight
of the ball. Some definitions;

* asynchronous = absence of "blocking" calls in application code

* I/O = exchange of data blocks between a process and and some
part of the operating system

* block stream = a sequence of data blocks; complete and orderly

* manager = something that can be "opened" to initiate I/O and therefore
processing of a block stream

* controller = some entity within a process that is interested in a
block stream and will therefore negotiate with a manager

* 2-way block stream = simultaneous read and write (i.e. network connection)

* codec = asynchronous coding and decoding of application data to and from a
block stream (AKA marshalling, serialization)

For me at least the major goals are prevention of blocking (asynchronous)
and re-use of codec technology across all variants of block streams.

Useful paths of discussion (IMO ;-)?

* possible managers - winsock, filesystem
* definition of interactions (between controllers and managers)
    open (controller -> manager)
    connected (controller <- manager)
    read (controller <- manager)
    read (controller <- manager)
    ..
    end (controller <- manager)
* mechanisms for exchanging messages (i.e. as above)
* should IPC mechanism (as above) be re-usable in other areas, i.e. not
specific to asynchronicity? even pluggable?

To help keep things murky....

I have implemented something with the above goals in mind. While thinking
 "pure async" I got fairly close but as others have pointed out the model
for
interaction WRT sockets manager does not overlay well onto the filesystem
manager.
Said another way - applying an async approach to what is normally sync
processing
of a file looks lame and unwieldy. But thats probably got more to do with
the (dreaded) paradigm shift and is therefore not necessarily "wrong".

Lastly, I have (re-)used the codec technology in sync operations, e.g.having
received
an async message across a network connection, in my responding state machine
I sometimes record a new state image in a file with a single blocking call.
What's with
that!? Well either I was just being lazy or its perfectly valid to make such
judgement calls. While expending great effort to remove blocking calls it
doesnt
mean that they are verboten.

Confused? :-)

Cheers,
Scott

ps: did mean to send to your new subject