read_owned and write_owned

[sinhpham]

My use case: keeping the lock guard tied to an object

struct MyStruct {
    // .... data
    lock: OwnedRwLockWriteGuard
}

It's similar to tokio's RwLock API: https://docs.rs/tokio/latest/tokio/sync/struct.RwLock.html#method.write_owned

[sinhpham]

@yoshuawuyts @sunfishcode I can work on a PR if this is a feature fd-lock wants to provide.

[sunfishcode]

Yes, I believe it makes sense for fd-lock to provide this, and am able to review patches for it.

[dpc]

I keep trying to use fd-lock in my projects, because I'm a forgetful dummy, and it appears on top of crates.io search, and then I keep hitting these artificial limitations, where all I really need is something to call the unlock on drop on the file descriptor.

The missing owned guards are a part of it, but eg RwLock::write taking &mut self is another one. An FS lock is not an in memory lock responsible for memory safety so what's the point of extra limitations of &mut?

There doesn't need to be "read" vs "guard" distinction. It's not a std::sync::RwLock. Creating two just makes it neccessary to create enum Guard { Read(...), Write(...) } if you need to store them. While in reality both Unix and Windows will call the same thing under the hood when unlocking read/write, and any future platform could do the enum trick.

Edit: For my future dummy self: Seems like all you ever wanted was https://docs.rs/fs-lock/latest/fs_lock/