You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@celix.apache.org by "pnoltes (via GitHub)" <gi...@apache.org> on 2023/03/31 12:17:50 UTC

[GitHub] [celix] pnoltes commented on pull request #476: Feature/refactor bundle cache

pnoltes commented on PR #476:
URL: https://github.com/apache/celix/pull/476#issuecomment-1491842260

   > The caller of `bundleArchive_getLocation`, say `lbCommand_listBundles`, could access memory freed by `bundleArchive_revise`, which is called by `celix_framework_bundleEntry_refreshBundleEntry` on a non-event-loop thread.
   > 
   > Similar consideration applies to `bundleArchive_getCurrentRevision`. But I'm not sure that usage of `bundleArchive_getCurrentRevision` in current code base is unsafe.
   
   I refactored the lbCommand to use celix_bundleContext_useBundles. 
   The non celix prefix api (bundle.h, bundleArchive.h, etc) are indeed not always thread safe. My goal is to make the celix prefixed api in combination with the celix_bundleContext_useBundles (or trackBundles, useServices, etc) thread safe. 
   
   The refactored lbCommand should be thread safe, because it use the celix_bundleContext_useBundles and only accesses the celix_bundle.h api during the useBundles callback. 
   
   After this PR I think we should do a minor Celix release and then prepare for a Celix 3.0.0 release. The primairy goal of the first Celix 3.0.0 release should be to remove all not celix prefixed headers for the users. This gives us more room to refactor older code and remove unsafe parts.
   


-- 
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-unsubscribe@celix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org