-
Notifications
You must be signed in to change notification settings - Fork 89
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
Ensure compliant init options API implementations. #200
Conversation
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
rmw_cyclonedds_cpp/src/rmw_node.cpp
Outdated
|
||
rmw_ret_t ret = rmw_security_options_fini(&init_options->security_options, allocator); | ||
if (RMW_RET_OK == ret) { | ||
allocator->deallocate(init_options->enclave, allocator->state); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me, the only thing that I find debatable is the handling of finalization failures. There are essentially dragons whichever way you turn unless you can always decide that finalization won't be successful before changing any state. And that seems to be unlikely in the general case.
Ignoring the gap between theory and practice, finalization failures are only possible if the environment was changed in invalid ways (e.g., DRAM failure, application deliberately freeing something it didn't own, etc.). In my view, that means "finalization never fails" (and therefore aborts on error) is a generally preferable over one where the state becomes undefined on error.
(For example, the close()
system call used to have an interesting failure more on some Unix implementation(s). Sadly, I have forgotten the details ... probably something like the file descriptor might or might not be closed, and if closed, another thread could cause it to be reused before the thread calling close
could even inspect the result. Therefore making it impossible to handle the erorr correctly under all circumstances.)
(End of "old greybeard mode" 🙂)
Yeah, there's that path too. But it seems to me that for finalization APIs, we're a bit late to the |
Yeah we discussed this before but essentially we saw the return codes as a way to more easily assert how it failed in tests, and because the caller can always choose to abort anyways. |
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Alright, fini API contract and implementation have been updated (see last commit in ros2/rmw#244 for reference). One last sanity CI run: |
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Complying with ros2/rmw#244.