Re: [Boost-users] [iostreams] Devices and WOULD_BLOCK

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
> 
> http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/guide/asynchronous.html
> 
> 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/