Re: [boost] Re: Asynchronous I/O

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

Hi,

----- Original Message -----
From: "Don G" <dongryphon_at_[hidden]>
To: "boost" <boost_at_[hidden]>
Sent: Thursday, March 24, 2005 4:34 PM
Subject: [boost] Re: Asynchronous I/O

[snip]

Patrick Mézard wrote:
> By the way, there were and will be lengthy
> discussions about which approach is the "best" to
> build scalable concurrent programs. I think that
> multithreading and event-driven programming were
> proven to be equivalent from a theorical point of
> view, but there real differences in implementation.

It's so hard to find the "best" isn't it? :) Of course, there is
seldom a consistent "best" even when an objective measure can be
produced (which is almost never) because the result depends so
greatly on the scenario or use case.

Perhaps the key ingrediant to "best" is "widely used" or "commonly
accepted". If you pause to think about it, a standard technique (that
wasn't gratuitously inefficient) that everyone could just use would
be better (IMHO) than a more optimized, but niche/non-portable
technique.

<inserted>
Interesting links (thanks to Patrick). Agree with most everything
being said and wonder at the scope of this topic - where does
it end?

There seems to be a lot of internal and/or platform specific detail.
While you need this for an implementation I keep coming back
to question in my head; what are the goals?

For me its a set of concepts and at least 1 implementation on
at least 1 platform.

What does that mean? Well something like the following....

If we were targeting async I/O for files what would that look
like? For me its a conversion of code that used to look like;

    handle = open( name, flags... );
    count = read( handle, buffer... );
    while(count != 0)
    {
        if(count < 0)
        {
            break;
        }
        process( buffer, count );

        count = read( handle, buffer... );
    }
    close( handle );

Into a series of notifications, i.e. callbacks

    controller::opened( handle )
    controller::data_ready( session )
    controller::data_ready( session )
    ..
    controller::closed( session )

The sequence and timing of calls to these methods
is not under the control of the application. It would
be driven by the async I/O library for the host file
system. Of course the above only shows one side
of a two-way relationship. The application would
probably initiate things with a call like;

    file_system::connect( name, controller );

For me there needs to be definition at this level; formalization
of concepts. With that kind of thing in place its possible that
we might one day write (async) code that moves without change
from sockets to files. Its what might keep the tech-talk on track.

Or am I in the wrong thread?

Cheers.

</inserted>