[Bf-python] data corruption

[Gilbert, Joseph T.]

This relates to an old discussion I had with someone on IRC.

One of the concerns that arose was that when a script as a GUI and wraps
some data internal to blender and a user deletes the object from the
scene - that wrapped data is now out of scope.

The 'solution' was to have python increment the us.id so that it would
not go to 0. This way we could be sure that the underlying data would
not be cleaned up and would still be available to the script's UI.

I'm not completely happy with the id.us solution but it seems the
simplest thing to do so far. id.us is the ID strut's user count and it
shows how many users there are on an object. Python should be considered
a 'user' is the idea here.

I am not sure if objects behave the same way as other data. If an
armature data block has an id.us of 0 it's not freed (because we set it
to zero manually when the object is created). Maybe what's happening is
that when a user manually deletes an object from a scene somewhere the
free() code for that object is called?

This relates in a larger sense to the idea of locking data internally.
If we have multiply things writing/reading to/from a piece of data
internally - how do we get/release locks on the object? How do I tell a
piece of data internally that it should not be freed because python is
wrapping it? This has applications with threading as well. (multiple
python gui scripts)

It would seem to me that we should check to see if:
1) setting the id.us of an object really forces the object data to be
freed
2) if manually deleting an object is the cause of the free

If setting the id.us to 0 does not cause an automatic free then there
doesn't seem much purpose in giving python a user count. 
If might still make sense if some sort of GC is implemented but if the
id.us is only used to count unfreed memory blocks on exit it doesn't
seem to have a big purpose.

Anyways just a few ideas.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Ken Hughes
Sent: Thursday, November 17, 2005 12:19 PM
To: Blender Foundation Python list
Subject: Re: [Bf-python] data corruption

Toni Alatalo wrote:
> On Thursday 17 November 2005 13:51, Toni Alatalo wrote:
> 
>>.. well that seems to be the same in the versions from 2 months ago
too, i
>>could not find any changes here in the recent commits
> 
> 
> went through the changes in Object.c since alpha2 (after confirming
the 
> problem is not there, thank god!) and did not see anything that could
cause 
> that.
> 
> Ton is coming here soon so i'll ask him if something has related in
the 
> internals that causes this. 
> 
> also tested that getting the same selected object (the default cube in
the 
> default b.blend) with Object.Get('Cube') does not mess the count up,
so it is 
> really just a GetSelected() issue. 

We tracked the bug problem down to a recent commit to Object.c which was

decrementing id.us in Object_dealloc().  Some, but not all, of the 
PyObject_NEW() calls to create BPy Objects were incrementing id.us. 
GetSelected() was not one of them.

I recall seeing a discussion in IRC related to this. I think the idea 
was that since objects and scenes are the two things in Blender which 
are deleted when their usage count reaches zero, this caused corruption 
if the UI deleted an object Python was wrapping.  This patch appears to 
let Python keep its own reference to the object so that Blender doesn't 
destroy it.

Toni and Ton discussed this and didn't see anything wrong with doing it,
and agreed we should just make sure it's done when every object is 
wrapped.  I consolidated the various PyObject_NEW() calls to all use 
Object_CreatePyObject().

Our question to you: is this the intention of this patch?  If so, is 
there a better way to do it?

Ken
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python