|
Boost : |
Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-11-02 04:57:51
On 2 Nov 2016 at 11:48, Gavin Lambert wrote:
> On 1/11/2016 21:41, Niall Douglas wrote:
> > You also don't need to use completion ports like ASIO does for async
> > i/o on Windows which are slightly complex to use. There is a much
> > simpler solution called alertable i/o which AFIO v2 uses which has NT
> > dispatch for you all pending async i/o callbacks every time you sleep
> > a thread. Examine AFIO v2's source code for ideas if you like, you
> > can throw together an async pipe i/o multiplexed reactor with very
> > little effort in no time because NT has already implemented an "ASIO"
> > for you, no ASIO needed.
>
> Having written my own mostly-lock-free ASIO-lite based around completion
> ports, I can confirm that they're not at all complex to use. Meanwhile
> I shy away from alertable I/O because it's thread-affine and requires
> remembering to always perform alertable waits, both of which seem
> fragile to me. Still, the advantage of both methods existing is that
> you can use whatever you feel most comfortable with. :)
It's true a lot of people will be surprised AFIO v2 has a totally
different async i/o engine design to ASIO. The easy answer is that
POSIX AIO gives you no choice, but the fuller answer is that I had a
small contract last year to give some expert consulting advice on a
very, very high end storage system which was experiencing unhelpful
random latency spikes. I benchmarked IOCP vs alertable vs
synchronous, and the performance increased in exactly that order i.e.
synchronous is easily the fastest, alertable not bad if you don't
overload a given thread, IOCP awful.
AFIO therefore requires you to run your afio::io_service on the same
thread as you do your async i/o, and pushes the problem of work
distribution across threads onto the user, totally the opposite to
ASIO's quite complex work distribution engine which judging from
recent Stackoverflow posts is becoming an increasing bottleneck for
many users on recent high end hardware. If you're a user with a > 3M
4Kb IOPS storage system then you really badly want to pin code to CPU
cores and very tightly manage hardware concurrency anyway. Anything
AFIO imposes would make using AFIO a showstopper for such users.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk