-
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
Feature/556 osgi uninstall #569
Conversation
It fixes #561, an ABBA deadlock in test, and a potential double-free.
Unloading a bundle from a framework instance will release all its resources but leave the bundle in cache so that it can be reloaded using `install`.
It fixes thread-safety issue in dependency manager (see #561), a null string logging issue in pubsub's topology manager, and a potential crash in query_command.c.
Codecov Report
@@ Coverage Diff @@
## master #569 +/- ##
==========================================
+ Coverage 78.08% 78.28% +0.20%
==========================================
Files 229 230 +1
Lines 35016 35013 -3
==========================================
+ Hits 27341 27409 +68
+ Misses 7675 7604 -71
... and 6 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Could you help review this? @pnoltes |
Yes, happily. Please allow me a few days to find the time to thoroughly review this. |
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.
Nice changes and good to see the unload addition and that the update bundle is now possible.
I do have some remarks for the recursive mutex and that the read lock is only used with useActiveBundles
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.
LGTM.
Maybe the useActiveBundle doc can mention that the framework ensures that the bundle state cannot change during a callback.
To fix #556, #557, part of #561, and #563, this PR introduces:
celix_framework_useActiveBundles
, which holds the per bundle read lock when calling the provideduse
callback.The bundle state is guaranteed to be active during the callback. For other cases like
celix_bundleContext_getBundleSymbolicName
, such strong guarantee is not needed. Therefore,celix_framework_useBundles
is still there.celix_framework_useActiveBundles
will lead to ABBA deadlock while callingcelix_framework_useBundles
will not. The test bundle (tst_activator.c) registers several subscribers synchronously, waiting the second registration to return (i.e. waiting for the event loop). The event loop is trying to add the second subscriber intotopicReceivers
, waiting formanager->topicReceivers.mutex
. The owner ofmanager->topicReceivers.mutex
is callingcelix_framework_useActiveBundles
, trying to hold test bundle's lifecycle read-lock. Unfortunately, the write lock is held before calling the test bundle's activator start.uninstall
of semantics similar to OSGi specs. It removes the bundle from the bundle cache and returns the bundle id to the framework.unload
operation, which is similar touninstall
but leaves the bundle in cache, so that next time reloaded from the cache, the bundle id does not change. To avoid any confusion, it is used only for testing purpose and is not exposed.update
implemented asunload
plusinstall
, avoid any bundle state inconsistency (Bundle state inconsistency in case of update failure #563) in case of update failure.celix_bundle_libs
andadd_celix_bundle
.I plan to add thorough whitebox tests to the life cycle layer and the module layer after this merged and #522 implemented.