pnoltes commented on PR #627: URL: https://github.com/apache/celix/pull/627#issuecomment-2111017532
> **Second lifetime approach: Spawn a thread** My second approach is to just spawn a thread in the start function and join it in the stop function. By this we get a scope that lifes from start to stop. We send the created `BundleContext` into the thread but also here we only provide the user a `&BundleContext`. Also here the user can not spawn thread that outlive the scope. But as the scope is from start to stop it is possible to create threads that also live as long. In the stop function we signal the thread that it must stop and join it. The user is responsible to make sure the thread stops. With this approach we do not need to store user data in the activator. We simply put a `JoinHandle` there to join it and the `Sender` to signal the thread it must stop. Overall this method is suited for static services but dynamic services as well. > > In the following repository I show how I think this could look like: https://github.com/kulst/celix_rust_test > In my opinion I would be great if the BundleContext and everything created from the bundle context can be controlled by lifecycles. This could ensure that we can have static checks for correctly handling service registrations and service usage within the lifecycle of a bundle. For now I also think it is fine to do this with spawning threads, but ideally a thread is not needed. I have experience with complex applications using about 100 bundles and this would also mean a 100 thread (including a 100 extra stack stack) purely for lifecycle management. If I understand it correctly a thread is used to ensure a object lifecycle from BundleActivtor::start until BundleActivator::stop. Is it not possible to somehow create a rust object that outlives the celix C framework, maybe even using a custom rust celix launcher and use that rust object to store "bundle lifecycle control" storage objects? But I am guessing here.. I am still learning rust. -- 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
