pnoltes commented on PR #627: URL: https://github.com/apache/celix/pull/627#issuecomment-2111071301
> **Final hurdles** I would like to rewrite the POC in the next step to make sure all of this works. However there is one problem I could not solve yet: What if a service of a bundle provides a 'static reference in its interface? The reference could point to 'static data of the bundle. After unloading the providing bundle this reference would be invalid. There should be a way to constrain the lifetimes to the lifetime of the service use callback. However I do not know how yet. Maybe there is a way by checking the service API with an additional proc macro. > Indeed. The integral dynamic nature of dynamic services in Apache Celix is that they can come and go and users should be protected against misuse as much as possible. For C / C++ this is arranged by providing a "use service" API based on callbacks so that the framework can ensure services are kept "alive" during callbacks. But it can also be done by service trackers combined with set/add/remove callbacks and in that case the user is responsible for correctly using the callbacks and protection service usage. I agree that ideally in Rust this should be done in a safer way, but lack to rust experience to know how or even if this is feasible. > **Summary** Again a lot of text. I hope you are fine with documenting my thoughts and progress here. There are a lot of topics that need to be considered. At the moment Rust is not perfectly well suited for dynamic linking. Its mostly unstable ABI makes it necessary to heavily use the macro system to provide a safe interface. If you want to have all of the Rust safety guaranties as well, a lot of possibilites need to be considered. But I still think it is possible and I will continue working on it. No worries, I find very interesting to read up your thoughts, ideas and POCs. IMO communication through PR comments are ok :) -- 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
