> > I feel that changing DS to perform service registration synchronous
with
> > bundle activation will likely result in deadlocks when there are
complex
> > service dependency graphs.
>
> This won't be any different from what is done now manually. The
> potential for deadlocks are there regardless of DS.
>
Perhaps, but at least we are not building it into the DS spec or the DS
impl!
> >
> > One possible way to deal with this is through the use of component
> > enablement. Using the original example of service A depending upon
some
> > number of service B, if you can know when all the service Bs are
> > available, one can write a component with a dynamic dependency on B.
> > When all the Bs are available then enable the component providing
> > service A (which are declared disabled in its description). The trick
is
> > of course to be able to know when all the service Bs are available
such
> > that we are ready to enable serviceA.
>
> And we are back to the core problem: we cannot be sure when all service
> Bs are available.
How can you ever be sure? :-) Unless there is some definition of the
expected set of Bs, it is just random.
> In code which doesn't use DS, start() method will
> serve as a boundary for the service changes - satisfied services will be
> registered while the bundle is starting and any services which becomes
> satisfied will be registered synchronously (the latter is the current
> behavior of DS).
This makes the assumption that bundle will always register their B during
BundleActivator execution. I think this is a fairly tall assumption. What
if a bundle's B depends upon something which is not yet available? It is
very bad form to block the BundleActivator. So such a bundle, if well
behaved, would have to return from the BundleActivator w/o having
registered B and delay registering B until the dependency is met some time
later.
> After all the bundles are activated, we can be sure
> that all services which doesn't depend on external factors will be
> available and the system can be considered ready.
>
You assume ("all services which doesn't depend on external factors") that
all B's have no dependencies and can be registered at will. That is a
pretty big assumption.
Perhaps one thing a DS impl could do, is to register all services for
which all dependencies are currently met synchronously during bundle
activation. All other services would have to handled asynchronously. This
splits the DS work between work that can be quickly done during bundle
activation and work that will take time which is done after bundle
activation. I don't think any change to the DS spec is needed to allow
this behavior.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
