Ichthyostega
d6167c1845
This is borderline yet acceptable; A service might indeed depend on itself circularly The concrete example is the Advice-System, which needs to push the clean-up of AdviceProvicions into a static context. From there the deleters need to call back into the AdviceSystem, since they have no wey to find out, if this is an individual Advice being retracted, or a mass-cleanup due to system shutdown. Thus the DependencyFactory now invokes the actual deleter prior to setting the instance-Ptr to NULL. This sidesteps the whole issue with the ClassLock, which actually must be already destroyed at that point, according to the C++ standard. (since it was created on-demand, on first actual usage, *after* the DependencyFactory was statically initialised). A workaround would be to have the ctor of DependencyFactory actively pull and allocate the Monitor for the ClassLock; however this seems a bit overingeneered to deal with such a borderline issue |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||