You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello there 😄 —
I am currently exploring System.Composition (v9.0.1) in a playground project and discovered an unexpected order of disposal for the parts created.
Let’s consider the following setup, where we want to obtain an instance of a Service:
class Service(IDependency dependency) : IService, IDisposable {}
class Dependency() : IDependency, IDisposable {}
The creation order for the parts is Dependency followed by Service, since Dependency is required for the construction of Service. On disposal of this composition container, we will discover the parts to be disposed in the same order as they are created (Dependency then Service).
To provide a possible example where this may be an issue — let's say for instance our Service is running a Task that will be cancelled on disposal, then there may be a race condition as its dependencies could already be gone and the relying service is still operational.
Granted, parts are generally not expected to still be used at the point the container is being disposed of — yet there may be scenarios where this is not as simple in the context of weak events.
Regardless, the order of disposal is unexpected to me and a reversed disposal order would seem more natural (and one could argue if that would mean more correct).
I am assuming that from an ownership perspective, the container is responsible for the disposal of the parts — particularly since the parts themselves have insufficient context, as their dependencies may be shared with others.
Could you help me understand if I am missing something, like a different lifecycle/ownership model?
Is there documentation or a consensus on why this was designed the way it is?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello there 😄 —
I am currently exploring
System.Composition (v9.0.1)
in a playground project and discovered an unexpected order of disposal for the parts created.Let’s consider the following setup, where we want to obtain an instance of a
Service
:The creation order for the parts is
Dependency
followed byService
, sinceDependency
is required for the construction ofService
. On disposal of this composition container, we will discover the parts to be disposed in the same order as they are created (Dependency
thenService
).To provide a possible example where this may be an issue — let's say for instance our
Service
is running a Task that will be cancelled on disposal, then there may be a race condition as its dependencies could already be gone and the relying service is still operational.Granted, parts are generally not expected to still be used at the point the container is being disposed of — yet there may be scenarios where this is not as simple in the context of weak events.
Regardless, the order of disposal is unexpected to me and a reversed disposal order would seem more natural (and one could argue if that would mean more correct).
I am assuming that from an ownership perspective, the container is responsible for the disposal of the parts — particularly since the parts themselves have insufficient context, as their dependencies may be shared with others.
Could you help me understand if I am missing something, like a different lifecycle/ownership model?
Is there documentation or a consensus on why this was designed the way it is?
Thanks for your combined insight 😄
Beta Was this translation helpful? Give feedback.
All reactions