doc: a note about listeners disconnection (close #958)

docs/md/entity.md

@@ -15,6 +15,7 @@
 * [Pools](#pools)
 * [The Registry, the Entity and the Component](#the-registry-the-entity-and-the-component)
   * [Observe changes](#observe-changes)
+    * [Listeners disconnection](#listeners-disconnection)
     * [They call me Reactive System](#they-call-me-reactive-system)
   * [Sorting: is it possible?](#sorting-is-it-possible)
   * [Helpers](#helpers)
@@ -422,6 +423,22 @@ There are many useful but less known functionalities that aren't described here,
 such as the connection objects or the possibility to attach listeners with a
 list of parameters that is shorter than that of the signal itself.
 
+### Listeners disconnection
+
+The destruction order of the storage classes and therefore the disconnection of
+the listeners is completely random.<br/>
+There are no guarantees today and while a logic is easily discerned, it's not
+guaranteed that it will remain so in the future.
+
+For example, a listener getting disconnected after a component is discarded as a
+result of pool destruction is most likely a recipe for problems.<br/>
+Rather, it's advisable to invoke the `clear` function of the registry before
+destroying it. This forces the deletion of all components and entities without
+ever discarding the pools.<br/>
+As a result, a listener that wants to access components, entities, or pools can
+safely do so against a still valid registry, while checking for the existence of
+the various elements as appropriate.
+
 ### They call me Reactive System
 
 Signals are the basic tools to construct reactive systems, even if they aren't