-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove raw SessionHolder::Get
#18490
Remove raw SessionHolder::Get
#18490
Conversation
f62a0b4
to
11f8918
Compare
PR #18490: Size comparison from a6ed4d9 to 11f8918 Increases (9 builds for linux, mbed, nrfconnect, p6, telink)
Full report (9 builds for linux, mbed, nrfconnect, p6, telink)
|
Doesn't this just kick the problem around? Now we need to check existence in the Optional. SessionHolder is already acting as an optional. I don't really see how this helps. |
The point is that you should always be checking for existence with a holder, and this API is bolstering that mentality for forcing applications and protocol layers to think about that. If our goal here is to eventually make these look like standard smart-ptr constructs, As part of that, I want to eventually return a |
Problem
The
SessionHolder::Get
API returns the underlying SessionHandle under the assumption that one exists in the holder. It assumes callers have previously calledoperator bool()
to check to see if there is a valid session in the holder BEFORE calling this API.However, most consumers are lulled into thinking with that API that there is always a
SessionHandle
in that holder, which is not true since holders act as weak-references where the invalidation of a given session removes the referenced handles from all holders in the system.This results in crashes if clients assume incorrectly about the session stored in the holder.
E.g If a subscription is setup with re-subscription enabled, the invalidation of the underlying session results in a crash later at re-subscription time.
Fix
Fix the API to return an
Optional<SessionHandle>
at all times to make it clear that the holder MAY NOT be holding on-to a session.Consequently, I scrubbed and fixed all existing call-sites (including the buggy
ReadClient
one) to either test for the right invariance about session presence, or to return an error appropriately if the holder was not holding onto a session at the time.Test
Using the REPL, I setup a subscription to a peer, then called
CloseSession
to emulate the forcible termination of a given session to a peer, then waited for the re-subscription to kick-in.Validated that it crashed pre-fix, and correctly error'ed out post-fix.