Re: [boost] [RPC] Boost.Asio to write *concurrency ready* code

Subject: Re: [boost] [RPC] Boost.Asio to write *concurrency ready* code
From: microcai (microcaicai_at_[hidden])
Date: 2013-08-28 00:48:18

2013/8/28 Niall Douglas <s_sourceforge_at_[hidden]>:
> On 27 Aug 2013 at 12:00, boost-request_at_[hidden] wrote:
>
>> I am *not sure* if anyone else has made such discovery, anyway,
>> comment is welcomed.
>
> What you have discovered is well known I am afraid. Indeed, proposed
> Boost.AFIO from this year's GSoC implements an asynchronous chainable
> closure execution engine on ASIO, and you can read documentation on
> how AFIO is equivalent to Google's and Microsoft's WG21 closure
> execution engine proposals here:
>
> https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF
> IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho
> w_boost_afio_relates_to_exisit.html
>
> Paul did up a great matrix mapping APIs from those engines to AFIO
> equivalents at
> https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF
> IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho
> w_boost_afio_relates_to_exisit/comparison_of_afio_with_other_cl.html
> and
> https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF
> IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho
> w_boost_afio_relates_to_exisit/other_useful_comparisons.html.
>
> If we get time before GSoC closes, we may just go ahead and implement
> N3562
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf)
> using AFIO as it would be incredibly trivial to do so. However, the
> Boost community only voted closure execution support as third most
> important - they ranked directory change monitoring as highest, so
> that's what me and Paul are implementing now.
>
> (FYI to those interested, we're going to deliver some *seriously*
> performant directory monitoring. Testing of our direct kernel syscall
> based implementation
> suggests watching a 1 million file entry directory for changes will
> actually
> work on Windows, albeit pegging a 3.5Ghz 4 core machine at 75-85% of
> all CPUs.
> Linux sadly lacks the syscalls to match Windows, but a 100,000 entry
> directory may well work just fine)
>
> Niall

After digging into the proposed Boost.Afio library, I am afraid that
Boost.Afio *does
not* meet my standard of what a *good* library is.

Boost.Afio seems to support both  async and sync operation, but
obversely they failed
to design the proper API. Boost.Afio relay on Boost.Asio, but they
seems to ignore the
elegant Asio Style. They didn't even understand what makes Boost.Asio
a good library.

A good library is not about good features (although its importand) but
about element API.

For async file I/O, the asio style API like this

   boost::asio::fstream file(io_service);

   file.async_open("test.txt", "r", & handle_open );

that is way more powerfull that the complex

   auto mkfile(dispatcher->file(async_path_op_req(mkdir,
"testdir/foo", file_flags::Create|file_flags::ReadWrite)));

The api that Boost.Afio choose is too complex yet too stupid.
You might argue on me that the job which Boost.Afio tries to solve is
complex, but that doesn't be a good excuse to design such stupid API.

Boost.Afio is stupid.

As the "closure execution engine", Boost.Asio already have that, there
is absolutly no point in investigating yet another Boost.Asio for what
ever reasons.