On 6 Jul 2014 at 12:57, Bjorn Reese wrote:
All that said, I agree that Boost.iostreams' fundamental design failure is that it wasn't built atop a 100% async i/o framework like ASIO. Which is a shame, as STL iostreams could do with being replaced.
FYI, Gene Panov has submitted an async extension for Boost.Iostreams:
I remember this from last year. It seemed to me at the time (and now) a sort of std::async for iostreams implementation that pushed the formatting labour onto worker threads. If I am wrong on this, do say.
I have been helping him getting the patch to follow Boost convensions, but perpetual lack of time has prevented me from finalizing it. The current works is at:
https://github.com/breese/iostreams/tree/feature/async_stream/include/boost/...
As much as this might be worthy, what I had in mind was an iostreams that doesn't mind out of order data readiness, so if I schedule a gather read from offsets A, B, C and D in a file, and they complete in the order D, B, C, A with lumpy periods of time between completions, the iostreams framework gets on with processing instead of waiting around for all to complete. Such an iostreams framework may seem excessively complex, but it's latency optimal. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/