Re: [boost] [afio] Formal review of Boost.AFIO

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.

Niall

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