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
Currently, the API is rather unsafe, in that a service could be disposed as another service is using it.
We could combat this using an explicit resource management framework, wherein services are attained
via references, and those references can be released later. This provides guarantees to the calling code
that a service won't dispose itself while it's in-use.
We could accomplish the above using a sort of garbage collector, with a simplified implementation of
the reference counting algorithm, which is a fairly universal concept.
The advantage of this algorithm is that it gives us more information as to how the caller is using the provided
symbol, so we can make more informed decisions later.
The current APIs should not be affected by this change. In the case of a reference counter, Calls to get
should not be reference-counted to ensure backwards compatibility. Additionally, we should ensure that the
usual behaviour of disposing services (after a .get call) is still satisfied.
Find a basic implementation of this below:
constreference=Container.refer(MyService);constmyService=reference.current;// This won't do anything, as a reference to MyService is currently held:Container.remove(MyService);awaitmyService.runAsyncCode();reference.release();// The identifier is now removed.
In the case of Container.remove, it would probably be best to immediately remove the identifier from the map, to ensure compatibility with code that would expect the older behaviour.
One aspect of interest is calling reset when a reference is held: when that reference is released, should the identifier be immediately discarded? I personally think this would be wise.
The text was updated successfully, but these errors were encountered:
Currently, the API is rather unsafe, in that a service could be disposed as another service is using it.
We could combat this using an explicit resource management framework, wherein services are attained
via references, and those references can be released later. This provides guarantees to the calling code
that a service won't dispose itself while it's in-use.
We could accomplish the above using a sort of garbage collector, with a simplified implementation of
the reference counting algorithm, which is a fairly universal concept.
The advantage of this algorithm is that it gives us more information as to how the caller is using the provided
symbol, so we can make more informed decisions later.
The current APIs should not be affected by this change. In the case of a reference counter, Calls to
get
should not be reference-counted to ensure backwards compatibility. Additionally, we should ensure that the
usual behaviour of disposing services (after a
.get
call) is still satisfied.Find a basic implementation of this below:
A way to use this in services could be:
Questions
Container.remove
, it would probably be best to immediately remove the identifier from the map, to ensure compatibility with code that would expect the older behaviour.reset
when a reference is held: when that reference is released, should the identifier be immediately discarded? I personally think this would be wise.The text was updated successfully, but these errors were encountered: