Hi Hans, Robert and Patrick, My comments are below. Hans Malherbe wrote:
The main thread does the waiting.
In Windows NT you will either wait on the event flag in the OVERLAPPED structure or specify a completion routine and wait in an alertable state with the SleepEx or one of the *WaitFor*ObjectsEx functions.
That makes sense, and I have used that feature before. The hard part about putting this technique to use in a library is that it makes requirements on the behavior of main: it must be in an alertable wait. If I recall correctly, GetMessage/PeekMessage are not alertable. Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a callback when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
Yes, you are correct; this is a terminology challenged area for me<g>! In this case as well as the above, the application has to wait for completion in the correct manner - not so good for a library IMHO. 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. Thanks all! Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
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>
participants (3)
-
Don G -
Robert Ramey -
Scott Woods