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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-08-25 15:10:43

On 08/25/2015 07:45 PM, Niall Douglas wrote:
> On 25 Aug 2015 at 17:44, Thomas Heller wrote:
>
>> No, not at all, sorry. The file handle should be kept alive by the future
>> holding on to it and probably also by the continuations attached by
>> async_read.
>
> But that is *exactly* what is implemented. Anything which will use a
> file handle in the future increments its reference count. Once it's
> finished with the handle, it decrements its reference count. When the
> count reaches zero and we know it will never be used again, the
> handle is destroyed.

Important nitpick of your implementation: Not the shared state of the 
future but the value held in the future keeps it alive.

>
>> Anything else should be handled by the user. Furthermore, if
>> I'm not completely mistaken, do all OSes internally reference count open
>> file handles, why duplicate that in user space again?
>
> I don't see how this bears any relevance. It doesn't ever bear
> relevance to code using AFIO. I could change the typedef for
> afio::handle_ptr in the future for some reason, and code would not
> need to care usually.
>
> You're not, by any chance, saying that you think the AFIO design
> should be 1 afio::handle = 1 fd? And when you copy construct
> afio::handle, that calls dupfd()?

That is what I would expect from a handle copy constructor, yes. Note 
that there are also move operations and a user is still free to store 
handles in any "container" (including smart pointers or whatever).

>
>>> 3. You have stated that you dislike the idea of afio::future<T>
>>> having shared future semantics for the future handle. But can you see
>>> that it is not possible to schedule 100 parallel data read
>>> continuations onto a file open unless the handle has shared future
>>> semantics?
>>>
>>> After all, if it had future semantics, you could only schedule
>>> exactly one read to each file open because then you would consume the
>>> future. It would not be possible to schedule parallel operations on
>>> any single preceding operation!
>>
>> That's correct. However you miss an important point:
>> shared_future<T>::shared_future(future<T>&&)
>> Meaning, a rvalue reference to future<T> can be implicitly converted to a
>> shared_future<T> (same is true for shared_ptr and unique_ptr, BTW). With
>> that, no publicly facing api function should ever return a
>> shared_future<T>, in my book as this doesn't make a lot of sense when a
>> future is seen as a return value transport endpoint.
>
> Ah I think I'm beginning to understand now. You're assuming a world
> where only std::future and std::shared_future exist and the
> relationship between them is well understood.
>
> By which, I infer you're saying that one does not need anything more
> than std::future and std::shared_future in an asynchronous filesystem
> and file i/o library?

I didn't say there is no place for other things than std::future or 
std::shared_future. You should know that ...
BUT if you claim conformance to the Concurrency TS ...

>
> And therefore, the current approach taken by AFIO of custom futures
> is wrong?

... a design that clearly does not conform to anything defined in the 
standard and only the names coincide, then yes, I consider the design 
broken. In addition, I see no shortcomings in the design of 
std::future/std::shared_future that wouldn't fit your usecase.

>
> Would this summary of your criticism be correct? If it is, I can
> address all those points, but it'll probably be Friday as tomorrow I
> am away and on Thursday we have no electricity all day, so no
> internet nor computers.

It's a very short summary of it, yes. Please keep in mind that all I 
said was under the assumption that anything "future" like in AFIO (or 
the depend NotMonad library) is just like a shared_future/future with 
some extensions (you repeated that multiple times on the list).
If you have something different that's totally fine but needs other and 
special attention because fighting an uphill battle against an ISO 
standard is not easy. Especially after all the claims that have been made.

>
> Niall
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>