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-25 13:45:29

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.

> 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()?

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

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

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.

Niall

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