Jay Oster

With this implementation (and the `async-std` implementation on which it is based), read-heavy workloads will starve writers. Starvation occurs here: https://github.com/rust-lang/futures-rs/blob/1430b056e30f5a9bc2e1f1213e1134801b02dc57/futures-util/src/lock/rwlock.rs#L101-L106 by incrementing the reader count without regard for the...

I'm confident the issue is in `try_read` because any task that awaits on the `RwLockReadFuture` guard will keep the read state alive without allowing writers a chance to acquire; `try_write`...

The docs I pointed to in `parking_lot` describe a similar fairness policy. The first property of fairness discussed is that readers should not acquire the lock if there is a...

Yikes! 😳 Yes, this is a use-after-free. `LCDColor::Pattern(GRAY_PATTERN)` is constructed on the stack and dropped after `from` returns: https://github.com/pd-rs/crankstart/blob/5b289e55598af9b90ceda3e24dff354815171ea2/src/graphics.rs#L36-L46 The implementation in @boozook's crate (owned variant) has the same problem...

I believe any lifetime will work. It just might be a bit of an ergonomics issue for users. I tested this yesterday with MIRI and it seemed ok (apart from...

Do I take it that the assignment means you want (one of us) to submit a PR for this issue?

I think this implementation is correct. The somewhat limited testing I have done hasn't revealed any showstoppers. And I believe my reasoning for the lifetimes and shared/exclusive splits in the...

I'm going to revert this PR back to draft while I sort out potential unsoundness that I discovered. I'll have a full analysis later.

Ok, it is guaranteed Undefined Behavior that I found. The issue is that the `Bitmap` API surface assumes interior mutability, and that makes the new API unsound because it provides...

That looks solid. You don’t have `Rc`, which this PR struggled with. And you don’t have a read-only `get_bitmap_data`, so the interior mutability is not a concern!