eclipse-uprotocol / eclipse-uprotocol/up-rust
Passing a `std::sync::Weak` instead of a `std::sync::Arc` into `UTransport::register_listener` to support automatic knowledge of registration drop
- Dominant language
- Rust
- Stars
- 26
- Forks
- 18
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 6
Description
One aspect I really like about the `up-cpp` uP-L1 Transport API is that they have a concept of a [`Connection`](https://github.com/eclipse-uprotocol/up-cpp/blob/2c101d742c15642b4a7ce55a49372b432f014364/include/up-cpp/utils/CallbackConnection.h#L83) which gives them a nice API where even if they do not `unregister_listener`, the holder of the other end of the `Connection` can drop it in order to make the transport unable to call it anymore.
I think we could do the same in Rust by passing in a [`std::sync::Weak`](https://doc.rust-lang.org/stable/std/sync/struct.Weak.html) such that if the entity which is orchestrating the the `UTransport` wanted it to no longer be able to call it and in fact deregister, it would be possible to know that when the implementation attempted to call [`Weak::upgrade()`](https://doc.rust-lang.org/stable/std/sync/struct.Weak.html#impl-Weak%3CT,+A%3E-2).
Just something going through my mind as I looked at how I implemented `UTransport` to take an `Arc` a while ago.
Contributor guide
Research direction
Start at UTransport::register_listener and inspect the current Arc ownership and deregistration behavior. Compare the Connection pattern in up-cpp's include/up-cpp/utils/CallbackConnection.h, then determine the API, lifecycle, and test changes needed; done means dropped registrations can no longer be called and are deregistered automatically.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100