[boost] Re: Asynchronicity (long)

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-02 10:56:56

Hi Eddie,

Please find my comments below.

> The reason I posited a separate library for purely
> asynchronous I/O, rather than folding that into the
> network library, is that there are models in which
> an asynchronous I/O library may have nothing to do
> with network access. For instance it is possible in
> some operating systems to read/write files
> asynchronously. Should this come under the aegis of
> a network library? I do not think so since the file
> I/O will normally occur locally. On the other hand,
> remote access to files may be thought of as network
> functionality and it may be possible to do file I/O
> remotely asynchronously. So my point was simply that
> an asynchronous I/O model may be something that can
> be used by more than just a network library and may
> be considered separately.

I agree in spirit, but the details make a library of this kind
unlikely to work. For example, (on Windows) the techniques used for
async file I/O are completely different than async network I/O. Even
pipe I/O is just slightly different that file I/O. What I have found
is that all one can hope for is a pattern with which async operations
should be designed. The implementation details may be shared in some
cases, but not enough to make those much of a reusable library. For
example, I created a socket select/poll engine at work, and it was
highly portable for the purposes of sockets. It could be applied to
file descriptors in general on Unix, but as that was only helpful for
those platforms, I didn't give it much polish. Async file I/O has a
completely different implementation, as did async pipe I/O.

> The main reason for my argument is reuse by other
> libraries doing asynchronous I/O but which may not
> be network related. If the network library is going
> to support asynchronous operations, which is only
> natural because of the time it takes for things to
> happen over networks, other libraries not defined
> as "network" but still wanting to offer asynchronous
> I/O operations could use a general purpose
> asynchronous I/O library to achieve their ends also.

See above. The means by which asynchronicity is gained differs by API
and OS, making a general, reusable async I/O library impracticle.

> Of course all this is theoretical design. It may be
> that the ideas of a separate asynchronous library,
> asynchronous I/O library, and network library are
> unrealistic and one can not separate these things as
> cleanly as I would believe, but I still think the
> idea of having these libraries for re-use is the
> right one.

Some non-portable portions can be made reusable, but still specific
to a certain part of the overall async I/O problem. To me, this means
that the async I/O facility is of use to very few people and should
be concidered an implementation detail.

> Even just a separate asynchronous library could be
> used when not doing I/O but just wanting to provide
> asynchronous "background" operations for processes
> which have to be responsive to end-user input.

I agree; a general async library can go a long way to making async
programming real. The I/O problem is a thing to solve on top of that.

> Of course separate asynchronous libraries and
> asynchronous I/O libraries exist in C++ but their
> models appear to me to be essentially C procedural
> programming models. Modern C++ should be able to
> come up with things that are more robust and take
> advantage of possibly both OOP programming and
> generic programming knowledge.

That's the hope :)

Best,
Don

                
__________________________________ 
Yahoo! Messenger 
Show us what our next emoticon should look like. Join the fun. 
http://www.advision.webevents.yahoo.com/emoticontest