On May 12, 2018, at 3:04 AM, Gregor Mückl <[email protected]> wrote: > > Why a unique_ptr specifically? This forces the concept of a singular owner > onto users of OIIO. A shared_ptr would work just as well, wouldn't it? It > would trade a bit of reference counting overhead for not imposing a strict > single owner.
Here's my case for unique_ptr / single owner: ImageOutput is absolutely, completely a one-owner conceptual model, because you're appending to and altering the file as you make write() calls. It can't get any more stateful and single-owner than that. ImageInput is more subtle because the file itself is not mutable, but the ImageInput itself is very stateful and intended to be single owner. Until very recently, absolutely nothing about ImageInput was safe for multiple owners (most basically, you don't want one co-owner to close the file and the other co-owner to still need to read from it; more subtlety, it gets even more complicated with seek_subimage for multi-subimage or mip-mapped images). Very recently, we added some new API calls (read and spec calls that take explicit subimage & miplevel parameters) that have guaranteed thread safety, but ONLY AGAINST EACH OTHER. So shared ownership of an ImageInput is still unsafe for legacy code that uses the old methods, or basically any time that the app isn't being extremely careful about only doing those thread-safe reads concurrently but nothing else. The ImageCache/TextureSystem is careful to do it right with concurrency in mind, but I don't expect other apps to be safe, so it's better for them to think of it in terms of single ownership. I thought about shared_ptr, and it would certainly work. Note also that you CAN convert a unique_ptr to a shared_ptr if you need shared usage, and in fact we do so internal to the ImageCache, in this very review. But you can't go the other direction easily, so if we return a shared_ptr, it's takes a lot more care on the caller's part to try to enforce single ownership on the app side. -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
