The bug is fixed by locking a Layout for updates while a RecursiveShapeIterator is active. Also, RecursiveInstanceIterator behaves the same.
Layout updates are responsible for recomputing cell bounding boxes, annotating hierarchies (e.g. computing parent instances, top cells and hierarchy-ordering of cells) and quad tree building.
While a Layout is locked, Layout#under_construction will return true. Layouts in that state can be written, but reading the mentioned information may not render the actual state.
A RecursiveShapeIterator will lock the layout it is on once it delivered the first item. The lock is released when it reaches end.
This has one consequence when coding scripts in Ruby: as in Ruby, the lifetime of an object is extended until the garbage collector removes it, pending instances of RecursiveShapeIterator may lock the layout and updates will not happen.
To mitigate this, _destroy can be use to explicitly remove the iterator when it is not used any longer.
On Python, this situation arises, if the iterator is kept in a variable. The iterator releases the lock when it gets destroyed - this happens when such a variable goes out of scope or is reassigned.
The bug is fixed by locking a Layout for updates while a
RecursiveShapeIteratoris active. Also,RecursiveInstanceIteratorbehaves the same.Layout updates are responsible for recomputing cell bounding boxes, annotating hierarchies (e.g. computing parent instances, top cells and hierarchy-ordering of cells) and quad tree building.
While a Layout is locked,
Layout#under_constructionwill return true. Layouts in that state can be written, but reading the mentioned information may not render the actual state.A
RecursiveShapeIteratorwill lock the layout it is on once it delivered the first item. The lock is released when it reaches end.This has one consequence when coding scripts in Ruby: as in Ruby, the lifetime of an object is extended until the garbage collector removes it, pending instances of
RecursiveShapeIteratormay lock the layout and updates will not happen.To mitigate this,
_destroycan be use to explicitly remove the iterator when it is not used any longer.On Python, this situation arises, if the iterator is kept in a variable. The iterator releases the lock when it gets destroyed - this happens when such a variable goes out of scope or is reassigned.