feat!: make session an arc-like object #1347
Conversation
|
PR missing one of the required labels: breaking-change bug dependencies documentation enhancement new feature internal |
Allow transport defragmentation errors and fix dropping of old transport messages
|
@wyfo I've changed the base |
…search-dirs Fix erroneous parsing of `backend_search_dirs`
|
PR missing one of the required labels: {'dependencies', 'breaking-change', 'bug', 'new feature', 'internal', 'enhancement', 'documentation'} |
|
PR missing one of the required labels: {'breaking-change', 'enhancement', 'new feature', 'documentation', 'dependencies', 'internal', 'bug'} |
wyfo
added
enhancement
Bumps [quinn-proto](https://github.com/quinn-rs/quinn) from 0.11.3 to 0.11.8. - [Release notes](https://github.com/quinn-rs/quinn/releases) - [Commits](quinn-rs/quinn@quinn-proto-0.11.3...quinn-proto-0.11.8) --- updated-dependencies: - dependency-name: quinn-proto dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: Luca Cominardi <[email protected]>
Co-authored-by: Luca Cominardi <[email protected]>
Co-authored-by: Luca Cominardi <[email protected]>
Co-authored-by: Luca Cominardi <[email protected]>
…r_reliability Publisher reliability
…argo/quinn-proto-0.11.8 chore(deps): bump quinn-proto from 0.11.3 to 0.11.8
To determine if the entity is callback-only, the only elegant way I've found is the rule "handler is ZST means callback-only". Unless users starts writing fancy implementations, it should be correct 100% of the time. Session entities now uses weak references, except publishers because it would impact performances. Weak references also solves the issue of mass undeclarations before closing the session (when the session is an `Arc`), except for publishers. `Undeclarable` trait has been refactored a little bit to better match its use in the code.
Co-authored-by: Luca Cominardi <[email protected]>
The refactoring is quite deep, so this is the first (dirty) iteration which passes the tests.
|
Should we still merge #1334 merge first? |
|
It seems you already included changes from current |
The refactoring is quite deep, so this is the first (dirty) iteration which passes the tests.
The branch is based on #1334, which should be merged first