> On 7 Jul 2017, at 2:44 am, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Jul 6, 2017, at 8:42 AM, Steve Mills <sjmi...@mac.com> wrote: >> >> Why can't you spawn your own thread to do the recursive code? Create the >> NSThread, set its stack size, light its fuse to do the processing, and >> delete it. > > This. Although I would also consider looking at your code to see if it can be > refactored to avoid using recursion; a recursive algorithm can always be > turned into an iterative one that uses a (growable) stack data structure to > hold state. Unbounded recursion can be dangerous, especially when it’s > operating on external data. If you do stick with the custom-thread approach, > consider putting in an explicit recursion-depth check in your code so you can > abort it cleanly before blowing up the stack.
I guess the problem I’m having with refactoring the code to do less recursion is that it’s a network of objects dearchived from a file. The problem is all within -initWithCoder: for two particular objects. One of these objects has an array of the secondary objects, plus it owns two of the secondary objects (not held in this array). The secondary objects have a weak pointer to their owner, so the two that are owned decode these references. The secondary objects in the array are not owned by the array owner, but by another instance of the first object. This is really hard to describe in words… a diagram would make this clear, if I only I could attach one. The point is that the secondary objects are effectively co-owned by the first type of object, plus another instance of the first type of object but through the array. When dearchiving, the first type of object decodes its array of secondary objects. But in turn they will decode the weak reference to the object that owns them - another instance of object 1. Which is duly dearchived, which decodes its array of secondary objects, and so on and so on. This is not an infinite loop - it’s just a deep stack. Eventually all of the instances of object1 are dearchived, and the stack unwinds, connecting all the secondary objects with their owners and the arrays that hold them. The weak reference back to the owner isn’t absolutely required - if I remove that step from dearchiving, it’s much flatter, and I can reinstate that link directly for the secondary objects that object1 owns. Except for old files, which weren’t organised in quite the same way, and lacked the back reference and a strong ownership by the first object. When opening these files, the weak back reference is the only information that exists about who owns the objects in the modern incarnation of the design. So it has to be derachived in order to discover its owner, and that owner may not have been dearchived yet, hence the recursion. I don’t expect this to make much sense to anyone else, even if you’re interested, which I doubt. I’ve been wracking my brains to figure out a way to dearchive these objects without the deep recursion, but I can’t find a solution that works for both new and old files. I guess I should have designed it better in the first place, so these older files wouldn’t be an issue, but they are, so I have to deal with them. It might be possible to use a second pass over all objects of this kind to fix up the links, or maybe using -awakeAfterUsingCoder:… or setting some flags to control conditional dearchving across the series of objects… all of which are a bit kludgey in one way or another. All for the sake of a bit of stack depth in hand. So… unless someone has any bright ideas (or has even read this, very unlikely), I’ll ponder some more. —Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
