Re: Increasing stack size of NSDocument's open file thread
Re: Increasing stack size of NSDocument's open file thread
- Subject: Re: Increasing stack size of NSDocument's open file thread
- From: Graham Cox <email@hidden>
- Date: Fri, 7 Jul 2017 15:34:12 +1000
> On 7 Jul 2017, at 2:44 am, Jens Alfke <email@hidden> wrote:
>
>
>> On Jul 6, 2017, at 8:42 AM, Steve Mills <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden