Hi Brian, Before answering your questions, I think it is important to realize that most of the framework logic is handled on 1 thread. So in your example, using a factory (multiple services) is not enough. You would still need to spin up a thread in the service yourself.
Functionally there should be no difference between the 2. The celix_ prefixed functions are newer, with the added namespace, but also with an easier api to register services. So those are better to use. Do you experience any issues/differences with either call? In short, it should work like this: 1) create a new service factory and register, see eg for an old api example: bundles/logging/log_service_v2/src/log_service_activator.c:115 bundles/logging/log_service_v2/src/log_factory.c 2) user registered service using a service tracker or dependency manager For each new bundle using the service, a new instance is made. Perhaps this is where the problem is, the new service is created per using bundle. My previous reply didn't mention that. So if the consumers are from the same bundle, they will all get the same service (and not a new instance). See the javadoc for the factory at [1]. [1]: https://docs.osgi.org/javadoc/r4v42/org/osgi/framework/ServiceFactory.html Op ma 3 aug. 2020 om 21:55 schreef Brian Michael <brian.m7...@gmail.com>: > Alexander, > > What is the functionality difference between: > celix_bundelcontext_registerServiceFactory > bundelcontext_registerServiceFactory > > Also. I’m wanting the new service spin up per other bundle calling this > service. So I have org.Algo1 that wants this C service and I have org.Algo2 > that also wants this C service. From reading up it appears that the service > factory is what I want I think but I built one inside of Celix and it > doesn’t appear to be making a new service when I perform the multiple > calls. > > Thanks, > Brian > > Sent from my iPhone > > > On Aug 3, 2020, at 10:37 AM, Alexander Broekhuis <a.broekh...@gmail.com> > wrote: > > > > Hi Brian, > > > > Most of the services concepts follow the OSGi Specifications [1]. A lot > of > > theory can be found there. > > > > Regarding your question, a service factory does not provide a new service > > for each call, but for each service reference. So each component > requesting > > a service provided by a service factory, will get its own instance. This > is > > regardless of the usage of a service tracker or dependency manager etc. > > > > While it is possible to get a new service for each of the calls, I wonder > > if that is what you want. Reading your scenario, something like a > > threadpool makes more sense. There are no restrictions to adding a > > threadpool inside a component yourself, which is then used by function > > handling the calls. > > > > In utils there is a thpool implementation [2] available, which is used by > > some experimental code. I personally don't have any experience with it, > but > > perhaps it can help you. > > > > [1]: https://www.osgi.org/developer/specifications/ > > [2]: https://github.com/Pithikos/C-Thread-Pool/ > > > > > > > > > > > > Op za 1 aug. 2020 om 17:38 schreef Brian Michael <brian.m7...@gmail.com > >: > > > >> Hello, > >> > >> I have a question in regards to the service factory capabilities. I want > >> to have Celix churn up a new service for each call that is coming in. An > >> example would be say I have a function that is just stuck in a while > loop > >> for 3 minutes before it exits and it prints stuff to screen. I want to > be > >> able to have multiple calls coming in and running. Currently the > incoming > >> calls have to wait their turn in order to use the service. Does the > service > >> factory churn up a new service per call to take care of this or do I > need > >> to go another route? > >> > >> Thanks, > >> Brian > >> > >> Sent from my iPhone > > > > > > > > -- > > Met vriendelijke groet, > > > > Alexander Broekhuis > -- Met vriendelijke groet, Alexander Broekhuis
