A previous version of HappyLock supported ReadLocks and WriteLocks
// when used in a lock collection, it creates a shared lock instead of an exclusive lock
pub struct ReadLock<'a>(&'a RwLock);
The problem with this was that it became impossible to both support this API, and check for duplicate pointers. If ReadLock::get_ptrs returns itself, having both the read lock and the rwlock in the same collection would not be considered a duplicate. If it returns the rwlock, then we can't override the behavior. One solution to this problem might be to return a v-table struct, kinda like RawWakerVTable. Then we can have it hold a reference to the lock, plus functions which describe the intended behavior. Then we'd just need types that can override what vtable is returned.
There might also be a way to use the address of the RwLock while using a different v-table pointer, but I haven't found any way of doing that.
A previous version of HappyLock supported
ReadLocksandWriteLocksThe problem with this was that it became impossible to both support this API, and check for duplicate pointers. If
ReadLock::get_ptrsreturns itself, having both the read lock and the rwlock in the same collection would not be considered a duplicate. If it returns the rwlock, then we can't override the behavior. One solution to this problem might be to return a v-table struct, kinda likeRawWakerVTable. Then we can have it hold a reference to the lock, plus functions which describe the intended behavior. Then we'd just need types that can override what vtable is returned.There might also be a way to use the address of the RwLock while using a different v-table pointer, but I haven't found any way of doing that.