Make File cloneable

[jneuff]

Can we make File cloneable? As far as I can see, we could just derive Clone as Handle already implements Clone. Or is there anything preventing this?

My use-case would be flushing the file from different threads (or tasks). This should be no problem, right?

Awesome work @aldanor btw!

[aldanor]

Hi @jneuff, thanks for raising this.

Here's the problem: typically, if you clone something in Rust (like a string), you expect whatever you get back to be independent of whatever you've cloned. Unless it's a refcounted wrapper like Rc/Arc - in which case the refcount is increased and you get the same thing back.

If you allow cloning arbitrary HDF5 objects like File by cloning a handle (which increases HDF5 reference count in a thread-safe way), I believe this will lead to confusion and possible errors (since you will essentially get the same object back), since we'll be mixing both types of behaviour listed above.

For HDF5 object types that can be legitimately copied (i.e., there exists an H5*copy() API function), like property lists or datatypes, we implement Clone already (see, for instance, https://github.com/aldanor/hdf5-rs/blob/feature/2018/hdf5-rs/src/hl/plist.rs#L49), with the meaning of "copy this object".

Re: flushing a file from different threads should be no problem at all; humongous amount of time/work on this crate was spent on thread-safety. All of the crate tests run in parallel in multiple threads as well.

Maybe we could add something like

pub trait RefClone {
    fn ref_clone(&self) -> Result<Self>;
}

and implement it for all high-level HDF5 object types? Any better suggestions?

[aldanor]

Another option actually - implement Clone for all high-level objects, with it having the same meaning as Rc clone, but for copyable objects add a .copy() method instead.

[Enet4]

Another option actually - implement Clone for all high-level objects, with it having the same meaning as Rc clone, but for copyable objects add a .copy() method instead.

Indeed, this would line up better with the usual behaviour of Clone in the ecosystem, which doesn't necessarily perform a deep copy (e.g. &T, Rc<T>, ndarray::ArrayView<A, D> and so on). Given that safety is guaranteed even in concurrency, it seems quite reasonable to implement a shallow clone and rely on other methods for deep copies where available.

[jneuff]

Here's the problem: typically, if you clone something in Rust (like a string), you expect whatever you get back to be independent of whatever you've cloned. Unless it's a refcounted wrapper like Rc/Arc - in which case the refcount is increased and you get the same thing back.

If you allow cloning arbitrary HDF5 objects like File by cloning a handle (which increases HDF5 reference count in a thread-safe way), I believe this will lead to confusion and possible errors (since you will essentially get the same object back), since we'll be mixing both types of behaviour listed above.

Yes, you are right. For my use-case sharing something like Arc<F: Flush> is the obvious solution and also prevents accidental calls to close.

Maybe we could add something like

pub trait RefClone {
    fn ref_clone(&self) -> Result<Self>;
}

and implement it for all high-level HDF5 object types? Any better suggestions?

So far I had no need to copy/clone other HDF5 object types, thus I can't contribute here.