Hi, ----- Original Message ----- From: "Don G" <dongryphon@yahoo.com> To: "boost" <boost@lists.boost.org> 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>