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