PengZheng commented on code in PR #583:
URL: https://github.com/apache/celix/pull/583#discussion_r1250053187
##########
libs/framework/src/framework.c:
##########
@@ -1443,17 +1566,23 @@ static void *fw_eventDispatcher(void *fw) {
while (active) {
fw_handleEvents(framework);
+ double nextScheduledEvent =
celix_framework_processScheduledEvents(framework);
+ celix_framework_waitForNextEvent(framework, nextScheduledEvent);
+
celixThreadMutex_lock(&framework->dispatcher.mutex);
active = framework->dispatcher.active;
celixThreadMutex_unlock(&framework->dispatcher.mutex);
}
Review Comment:
There is indeed a lurking bug, which is triggered by
https://github.com/apache/celix/pull/583/commits/b2a79be9abd2c83949f13aace4f2f695ff5c794c:
https://github.com/apache/celix/actions/runs/5436850610/jobs/9886984957
`framework_shutdown` has been spawned by `frameworkActivator_stop`, which is
in turn called by `celix_framework_stopBundleEntryInternal`. Before stopping
the event dispatcher, we have to make sure
`celix_framework_stopBundleEntryInternal` has been finished. Otherwise,
`fw_fireBundleEvent(framework, OSGI_FRAMEWORK_BUNDLE_EVENT_STOPPED, bndEntry);`
in `celix_framework_stopBundleEntryInternal` may produce a ever-lasting
reference to the framework bundle when we are in the process of stopping the
event dispatcher.
A true race-free solution is given in
https://github.com/apache/celix/pull/583/commits/b706d163543f403921498b5250244e561ad04298
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
