14 Jan
2015
14 Jan
'15
10:59 a.m.
The destruction of objects is deferred. this leads to destroy() being called at some later point (after error, function return, some io handling, etc). when destroy() calls any code which has cycle detection, this can lead to spurious errors. Imagine a destroy function which calls sprintfs with some global object (e.g. Val.null). Similar problems arise when destroy is called while some mutex lock is being held and destroy() tries to aquire the same lock. Of course in that case the cycle detection simply guards against deadlock.
What kinds of things can safely be done from within destroy() and should we document them?
arne