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/