On 15/06/07, Chris Spencer <[EMAIL PROTECTED]> wrote:
> On 6/15/07, Chris Bainbridge <[EMAIL PROTECTED]> wrote:
> >
> > The problem is that the destructor order is essentially random when gc
> > is used. ODE (not pyode) doesn't have any ownership rules for objects,
> > and objects point to each other, so deallocating objects causes memory
> > protection faults. This is also a problem with C++ ODE code, python
> > with gc just aggravates the problem. In my Simulator.__del__ function
> > I have something like:
> [snip]
>
> Thanks for the tips. I tried implementing a similar __del__ for my
> top-level object, but I still encounter the problem.

Are you sure your __del__ function is being called first? You might
need to rename it and manually call it from your shutdown function
before python starts garbage collecting.

> Since it looks like this problem isn't going to be fixed anytime soon,
> is there anyway to work around the issue? With my usage, the fault
> only happens when the Python process is terminating, but it's stopping
> a new process from being spawned. Is there any way to recover from it,
> or is this problem fatal?

You can ignore the return code? Not very elegant though.

You could stop using gc. Python has reference counting anyway, so the
only effect is that you need to manually remove cyclic links between
your objects from __del__ methods. It's quite easy with the gc module
to dump the number of objects of each type and see which ones aren't
being destroyed.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Pyode-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyode-user

Reply via email to