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

Subject: Re: [Boost-users] [iostreams] Devices and WOULD_BLOCK
From: David Hawkins (dwh_at_[hidden])
Date: 2015-01-22 11:31:07

Hi Niall,

>> 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.

Thanks for the insight. I appreciate the feedback I'm getting
from the experienced Boost community members.

Cheers,
Dave