4.7.5: Singleton instances differ between parent and child when first created within child container

[cnruehl]

Hi Maksim,
Hi all,

I am currently playing around with DryIoc 4.7.5 and gladly found that you have added IContainer.CreateChild().

I learned that by default a child shares all registrations and cached resolutions with the parent. Now I am wondering why this behavior is depending on where and when a singleton instance is created first. If it is created within the parent (prior to the child creation) then the instance resolved within the child is the same. But when the child was created before the singleton instance was created within the parent, then the instances resolved in both differ. Why is that so? And is there a way that allows me to avoid this behavior? When using a scope this works fine: All scopes share the same singleton instance, no matter where and when it was created first. I would like to have this behavior when using child containers as well.

Cheers,
Chris

[dadhi]

Hi @chrisg32 ,

My main problem with the child containers is that slightly different expectations on what and how should they work by default.
That's why it took me so long to provide the specific method CreateChild but anyway it does not solve everyone's problem.
Here is the current CreateChild implementation:

        public static IContainer CreateChild(this IContainer container, 
            IfAlreadyRegistered? ifAlreadyRegistered = null, Rules newRules = null, bool withDisposables = false)
        {
            var rules = newRules != null && newRules != container.Rules ? newRules : container.Rules;
            return container.With(
                container.Parent,
                ifAlreadyRegistered == null ? rules : rules.WithDefaultIfAlreadyRegistered(ifAlreadyRegistered.Value),
                container.ScopeContext,
                RegistrySharing.CloneAndDropCache,
                container.SingletonScope.Clone(withDisposables),
                container.CurrentScope ?.Clone(withDisposables));
        }

In your case the problematic like is the container.SingletonScope.Clone(withDisposables) - it means copying the parent singletons if any and preventing their disposal in the child based on the withDisposables parameter.
If you try to share the singletons by passing the container.SingletonScope instead, you will get what you need But the disposal of the child container will dispose of the singletons in the parent too. So we need something in between which is hard to achieve with the current approach.

I will think about how to do that and meanwhile, I am open to ideas.

[cnruehl]

Hi @dadhi,

Thanks for the fast reply. I already assumed that this would not be too easy... Anyways, I understand the potential workaround with using the SingletonScope but paying another price (disposal of singletons together with the disposal of a child container).

Temporarily, I could try to see if scoping solves what I am trying to do. But nevertheless, I am really interested to see what you are coming up with in the future. DryIoc is really a cool project and I really appreciate your dedication to it. I will stay tuned. :)

Cheers,
Chris

[dadhi]

@cnruehl
I will try to summarize my thoughts on the problems and possible solutions for the singletons between parent and child containers.

First, a few implementation details of the Scope class which is used both for the singletons and the scoped items:

• Scope stores the created service objects in one dictionary and only the disposable objects in the separate collection. It is done to speed up the Sope disposal by iterating over the disposables collection - this collection should contain fewer items than the dictionary and it should be faster to iterate.
• Scope Clone(bool withDisposables) method is cloning both collections if the withDisposables == true or creates the empty disposables collection if withDisposables == false.
• The container holds a single Scope for the singletons and calls the Scope.Dispose when the container is disposed of.

1 - Sharing the singletons scope

Let's imagine we have registered some singletons into the parent and then created the child without singletons Scope cloning - just sharing the singletons Scope instance. When the child is disposed of then all singletons would be. It is not what we need.

2 - Sharing the singletons items dictionary but not the disposables

When the singleton is first resolved from the child it will get stored in the child disposables but not in the parent disposables. When the child is disposed then the singleton will be disposed and no longer usable by the parent or other children.

3 - Sharing the singletons Scope but create the child container with the option to not dispose the singletons Scope

When the child disposed then no singletons will be disposed which is better.
So the new question arises - what to do with the singletons registered to the child? They will be stored and disposed of with the parent. Is this fine?

[TDB] Thoughts continue...

[cnruehl]

Hi @dadhi,

Thanks for sharing your thoughts! Variant 3 sounds pretty good, but I would expect the disposal of the singleton instances to happen when the container, which holds the registration is disposed. Example (pseudo code):

using(var parent = new Container())
{
   parent.Register<IFoo>(Reuse.Singleton);
   
   using(var child = parent.CreateChild())
   {
       child.Register<IBar>(Reuse.Singleton);

       var parentFoo = parent.Resolve<IFoo>();
       var foo = child.Resolve<IFoo>();
       var bar = child.Resolve<IBar>();

       Assert.AreSame(parentFoo, foo);
   }

   Assert.IsTrue(bar.IsDisposed);
   Assert.IsFalse(foo.IsDisposed);
}

Assert.IsTrue(foo.IsDisposed);

Does this make sense in your eyes? Or am I corrupting the scoping approach when I am trying to do things like that?

[dadhi]

@cnruehl yeah, It does make sense and poses a challenge.

If the singletons scope is shared (case 3) then when a child is disposed we should filter the child registrations from the scope and dispose them.
This filtering is costly because the scope stores the items by their intreger factory id (enabling more compact storage and faster access) but the registrations are stored by the service Type and the Key. I have a rough idea to index the registrations by their factory id just for the child container. The index will add the maintenance cost but I don't see any simpler alternatives at the moment.