Method collect

src/IECorePython/WrapperGarbageCollector.cpp:74–116

}

void WrapperGarbageCollector::collect()
{
	std::vector<PyObject*> toCollect;

	do
	{
		toCollect.clear();
		for( InstanceMap::iterator it = g_refCountedToPyObject.begin(); it!=g_refCountedToPyObject.end(); )
		{
			InstanceMap::iterator nextIt = it; nextIt++;
			if( it->first->refCount()==1 )
			{
				if( it->second->ob_refcnt==1 )
				{
					// add to the list of objects to destroy
					toCollect.push_back( it->second );

					// Make sure the object is removed from the list before the next loop, which
					// destroys it. This is because Py_DECREF() can run arbitrary, multithreaded python
					// code, (especially if the python object has a __del__ method) which may create
					// WrapperGarbageCollector objects, effectively making this method recurse. It's also
					// possible that this python code can call collect() directly. Removing the object
					// from the list here avoids double deallocation.
					g_refCountedToPyObject.erase( it );
				}
			}
			it = nextIt;
		}

		for (std::vector<PyObject*>::const_iterator jt = toCollect.begin(); jt != toCollect.end(); ++jt)
		{
			// decrement the reference count for the python object, which will trigger the destruction
			// of the WrapperGarbageCollector object.
			Py_DECREF( *jt );
		}
	} while( toCollect.size() );

	g_allocCount = 0;
	/// Scale the collection threshold with the number of objects to be collected, otherwise we get
	/// awful (quadratic?) behaviour when creating large numbers of objects.
	/// \todo Revisit this with a better thought out strategy, perhaps like python's own garbage collector.
	g_allocThreshold = std::max( size_t( 50 ), g_refCountedToPyObject.size() );
}

PyObject *WrapperGarbageCollector::pyObject( IECore::RefCounted *refCountedObject )
{