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/