Boost Users :
Subject: Re: [Boost-users] [iostreams] Devices and WOULD_BLOCK
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-22 11:22:42
On 21 Jan 2015 at 21:40, David Hawkins wrote:
> Right, I'd be happy using async code, but this particular feature is
> new with filtering_streams - per the documentation
> Since async support is new, it might not be fully supported (or at
> least fully debugged). Now that I am getting more familiar with
> the boost code, I need to dig around a little more in the
> Boost.Iostream example and test folders.
FYI I don't believe Iostreams has been substantially changed since
Boost 1.44. It is currently considered without a named maintainer.
Also, non blocking i/o is not async i/o, despite what Iostreams
claims in its docs and seems very confused about. Async i/o on files
lets you issue structured queue depth easily to an optimal level for
performance. Non-blocking i/o on files requires a lot more work to
achieve the same (and besides, non-blocking i/o on files isn't
supported on any major operating system, so Iostreams has to emulate
it using inefficient fragment i/o).
ASIO can do async file i/o, though support is not well tested, and
strong ordering of writes has to be done by hand. A library in the
Boost review queue AFIO which extends ASIO does do async file i/o and
makes life somewhat easier, though until coroutine support is added
you still end up writing fragments of completion handler like with
ASIO without coroutines.
AFIO also may add async NFS and Samba safe file byte range locking
soon. This is a real devil to implement sanely, but I believe I have
found a viable if evil algorithm.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net