Calvin

@parasyte At the moment what I have is this: https://github.com/rust-lang/futures-rs/blob/1430b056e30f5a9bc2e1f1213e1134801b02dc57/futures-util/src/lock/rwlock.rs#L417-L431 Which only wakes waiting readers if there are no currently waiting writers. Though, this is flawed at the moment since...

I see your point; so what you're arguing is that we establish more complex rules for acquiring read locks? I think that's doable and could work out fine. Perhaps something...

Nonetheless, I think it would suffice for now to allow the pull request to merge once it is deemed suitable. Dealing with fairness policies seems beyond the scope of this...

@najamelan The point I was trying to make is that this pull request is focused on the introduction of new data types that provide asynchronous read-write locks. The improvement and...

So I've managed to get an implementation together that can support fairness for Read/Write locks. However, I'm currently blocked. I believe that I will need to create custom waker functions,...

Alright, I'll see if I can make some adjustments. To clarify though, am I correct in avoiding the additional `Sync` restraint? Edit: Nevermind, the route I was going with was...

So, what I have is what I think should produce a fair read/write lock. The way it works uses a ticketing system. Each request for a lock takes a ticket...

@taiki-e Could you provide any help setting up a test environment. I'm unfamiliar with the general procedure for adding a new unstable feature to a package like this.

Alright, from what I managed to see, this should work and provide fair read/write locks. I managed to add in support for `try_read` and `try_write` without resorting to timers as...

I considered that, but I believe that it's likely that this would be a breaking change there.