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
Arne Goedeke wrote:
What kinds of things can safely be done from within destroy() and should we document them?
Well, I for one, "discovered" that *if* any code in destroy() can throw an exception, you must explicitly catch it, because if you don't the exception will be raised and (sometimes/always?) silently discarded.
Stephen R. van den Berg wrote:
Arne Goedeke wrote:
What kinds of things can safely be done from within destroy() and should we document them?
Well, I for one, "discovered" that *if* any code in destroy() can throw an exception, you must explicitly catch it, because if you don't the exception will be raised and (sometimes/always?) silently discarded.
Strange; do you have a test case? When I read the code it looks like any exceptions will be caught and sent to master()->handle_error().
pike-devel@lists.lysator.liu.se