On Mon, 31 Aug 2020 at 15:01, lampahome via Boost-users < boost-users@lists.boost.org> wrote:

I haven't tried any of these methods, but it does provide the

...

posix::stream_descriptor and windows::{stream,random_access}_handle classes which should be able to operate on native files. (You'll have to use a native OS-level function to open the handle/descriptor for the file and pass ownership to the ASIO object; they lack means to do the opening itself.)

Thank u. That gives me a direction. The only sad thing is very little document/examples described about this API of boost.asio .

This is a common complaint of Asio. If you would like to tap into a great body of knowledge and interest in asio/networking-ts you can do so by joining the #beast channel in cpplang slack https://cppalliance.org/slack/ Beast depends very heavily on Asio and we have worked to build a strong body of expertise.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Asio certainly has support for asynchronous file IO. I have used it on linux systems for a multitude of file handle types, including console I/O. On Tue, 1 Sep 2020 at 06:40, lampahome via Boost-users < boost-users@lists.boost.org> wrote:

If you would like to tap into a great body of knowledge and interest in

...

asio/networking-ts you can do so by joining the #beast channel in cpplang slack

If I'm interest in asynchronous io of file, do I try asio? What I look for is like libaio in unix system, but still found no wrapper/library to do like that.

thanks _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Hello, Niall Douglas Wrote:

Unless you were using a custom io_uring based i/o service, all your asynchronous file i/o on Linux was actually synchronous all along.

It doesn't really matter, whether the IO really is performed asynchronously. The asio API is asynchronously in the sense, that the completion handler is not called from within the async_*() call but later from within the main loop and the main loop does not block, while waiting for the IO operation to complete. It just happens to be the same Linux API, that is used for async socket IO and for async file io, since on linux systems, sockets are files. But: Things probably are different on windows systems, so there is no guarantee. 73, Mario -- Mario Klebsch                      Actia I+ME GmbH Mario.klebsch@ime-actia.de         Dresdenstrasse 17/18 Fon: +49 531 38 701 716            38124 Braunschweig Fax: +49 531 38 701 88            German

Richard Hodges via Boost-users 於 2020年9月1日 週二 下午6:54寫道：

Asio certainly has support for asynchronous file IO. I have used it on linux systems for a multitude of file handle types, including console I/O.

Is there any function can handle the finished IO operation?

Assume I have two threads. One is only submit async io to file, and another one is only handle event of those executed io. I only find handler function but wonder if any easier handler to handle all. thanks

On 31/08/2020 05:08, Gavin Lambert via Boost-users wrote:

Alternatively, there's another library (that I also haven't used) dedicated to async file I/O.  It originally started life based on ASIO but I think it's since diverged into something else.  And called something different from the last time I saw it as well.

Its current home appears to be: https://ned14.github.io/llfio/

Yes, one part of it should enter the C++ 23 standard, other parts may do so. LLFIO doesn't export publicly any async file i/o implementation however. This is because async file i/o usually has worse performance than synchronous file i/o. So you generally want to use synchronous i/o tightly integrated with kernel threads, if concurrency is desired (quite often it is not).

(The impression I have, which may be mistaken, is that it is possibly overkill for general application use, unless you're trying to implement some kind of custom database engine rather than just using an off-the-shelf DB library.)

Spot on. The only place where async i/o makes a lot of sense is where i/o latencies are unpredictable most of the time. This is usually the case with socket i/o latencies, it is rarely the case with file i/o (and as you mention, only in very high random access use cases across datasets far exceeding RAM does disabling caching for file i/o make sense). Niall