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

Reply via email to