Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-27 22:57:53

On 27 Aug 2015 at 15:31, Vinícius dos Santos Oliveira wrote:

> Anyway, maybe I can help here. I know Niall had played with Rust for
> sometime[1] (and end up eventually hating for the lack of an asynchronous
> foundation[2]). I too end up playing with Rust for some time and maybe
> that's why I understood Niall without trouble.

Hating is far too strong a word. Rust's standard i/o library can't do
select() on sockets and instead forces you to spin up a dedicated
kernel thread to sit around waiting for reads, and then provides no
way whatsoever of poking we-are-about-to-shutdown at that dedicated
thread. I got very frustrated working around that, as would anyone.
We're not stuck in the 1970s for god's sake.

Rust's standard i/o library is close to useless for real world
portable programming, that's all. They know this, and this time next
year they'll have a vastly improved standard i/o library.

> Anyway, a value that was consumed is a value that cannot be used again.
> There are consuming operations that will consume the value. It's closely
> related to the move idea, where the moved value is left in an unspecified
> state. There are moving operations and there are consuming operations, but
> consuming operations work on values other than rvalues too.
> Imagine a range that invalidates the original container. It *consumes* the
> container.
> Does that explanation help?

Remember that Hartmut and Thomas are coming from a standards-ease
perspective, and hence their disavowal of thinking in terms of
anything not termed in standards-ease. You may not be aware Vinícius
that Hartmut is a world leading expert in concurrency, and is one of
the main minds behind the Concurrency TS.

I in the meantime don't really care much about design purity - if I
did I would not write in C++. I do care about impure design causing
users to write dangerous code which will fail in unexpected ways, and
to that end consuming futures are usually superior. However in AFIO's
case the thing being transported with non-consuming semantics is a
shared_ptr, and both that and the handle it reference counts is
thread safe. This, as far as I can tell, eliminates any chance for
dangerous code being written by end users and is why I allowed that
design choice and it does save significant additional typing to be
written by end users.

But in the end, I'm no world expert on concurrency. I mostly design
by instinct not logic. My design choices are famously mongrel as a
result as you can see in afio::future<T> having dual future
semantics, one for the handle, the other for the T.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at