On Wed, May 01, 2013 at 06:32:46PM +0200, Miguel Angel Ajo wrote: > this is not a problem when calling pcbnew objects from outside pcbnew,
Unless from the outside you call something that deletes an object you have 'on hold' no, it's not a problem. Imaginary use case: Let's say a script want to delete a track segment; it take hold of the segment (searching around and stuff) and put it in a variable. Now I don't actually know how track segment are deleted in pcbnew, but, since it's imaginary, let's say that there is a board function that does this, given a segment pointer (which is a plausible way to do stuff, since usually object don't self-destruct). In pseudo-code: board = GetBoard() segment = board.FindSegment(stuff_im_interested_to) ... maybe other processing ... board.DeleteSegment(segment) At this point, since the segment object was deleted, the segment reference becomes invalid (usually trying to use it gives a segfault but anyway is undefined behaviour). It works, just be careful to not use it after that (or put a null inside to be sure, if python has the concept). The old SAFE_DELETE macro did something like that for C++ (delete x; x=0;). The problem exist in LUA too, BTW... actually since LUA is targeted toward C, object are implemented as userdata (to anchor in the LUA memory manager) but you have the same problem! The usual solution is giving all the objects away to LUA (you gain free garbage collection in the deal :D) but the object themselves must be coded specially for this to happen; for example you have to register finalizers *and* every time you take hold of another object you have to tell LUA that you have it, otherwise it will be collected. If you ever had the (dis)pleasure of coding COM object, the drill is the same. I don't know how python works but I don't think that would be a lot different... it would be great if there was a way to tell python "this object is no longer alive" and it would null all the references (just put the magic call in the destructors...); weak pointers in many languages works that way (only automatically :D) > from inside, it could be a problem if we multithreadWx does run as a single > thread event loop, or is it multithread? Never seen an ounce of thread synchronization in the whole kicad :D >From what I have seen it all run in the main event thread (or whatever thing in wx receives messages from the outside) -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp