To make my previous email more concrete (and revise things slightly), deactivating particles would involve: - telling the Model to delete the particle. That removes the pointer in the model and frees the index up to be recycled - the ParticleIterators in the model skip delete particles (skip null pointers) - the particle is marked as invalid and any accesses to it throw exceptions - all pointers to the particle are reference counted and the particle object is deleted when all of them go away
A slightly more complicated alternative which would delay recycling ParticleIndexes would be - marking them as inactive - The Model ParticleInterators skip inactive (and NULL) particles. Python people will just have to deal unless someone knows how to get custom iterators working in python - all pointers held by restraints are reference counted. When all of the pointers held by everything go away, the Particle entry is set to NULL in the model (and can be reused) and the particle is deleted. - the Model maintains a list of free particle indexes and reuses them once they are gone from the system
These proposals leave open the issue of making sure that particle indexes stored in the attribute table always point to the right generation of particle (i.e. make sure that the index doesn't get recycled before they get cleaned up). One solution to this would be to add a new attribute type, that of a particle pointer so these have full reference counted semantics. This would not be hard.
Daniel Russel wrote: > To make my previous email more concrete (and revise things slightly), > deactivating particles would involve: > - telling the Model to delete the particle. That removes the pointer > in the model and frees the index up to be recycled > - the ParticleIterators in the model skip delete particles (skip null > pointers) > - the particle is marked as invalid and any accesses to it throw > exceptions > - all pointers to the particle are reference counted and the particle > object is deleted when all of them go away
This sounds reasonable to me. I agree that the most sensible way to do this properly is to have a reference counted Particle-pointer attribute for Particles. But don't worry too much about the reference counting in Python - I can look at that. However, I suggest rather than a single pointer attribute we use a vector<Particle pointer> attribute. This would certainly make things like hierarchies much easier to implement (plus, much faster, since you could just cache a 'child' ParticleVectorKey rather than having to do a lot of lookups for child1, child2, child3 etc.) Pointers to single particles are probably sufficiently unusual that the overhead of a single-element list is negligible.
Ben
> However, I suggest rather than a single > pointer attribute we use a vector<Particle pointer> attribute. This > would certainly make things like hierarchies much easier to implement > (plus, much faster, since you could just cache a 'child' > ParticleVectorKey rather than having to do a lot of lookups for > child1, > child2, child3 etc.) Pointers to single particles are probably > sufficiently unusual that the overhead of a single-element list is > negligible. I agree that single particles are unusual. However, the overhead entailed by the current model is pretty small so it is not clear to mean having vectors would be noticeably faster. To access a Particle attribute the internal pseudo-code looks something like
check that the vector of child keys is long enough get the key from the vector get the particle
If we have a vector it looks like
get the key for the children get the vector of children get the particle
so you just save one check which generally succeeds. As a result I would vote for not complicating the interface by having the particle attributes look different from the others. Mostly an aesthetic preference, so not very strong.
participants (3)
-
Ben Webb -
Daniel Russel -
Daniel Russel