> On 6 Jul 2017, at 11:04 pm, Alastair Houghton <alast...@alastairs-place.net> > wrote: > > There’s no way an API could exist that did that - in general it’d have to > copy the entire existing stack to a new location, then update a load of > pointers that it has no obvious way to find (otherwise the moment you return, > everything will go wildly wrong). >
I appreciate your answer, and I realise there’s no API that could set the stack size after the thread is created. But presumably the stack size of the thread is set somewhere as a parameter to the thread when it’s created - certainly if I create a thread myself it’s one of the attributes. So the question is is there a way to set up a value that NSDocumentController will use when opening a file? The default stack size seems very small, considering that dearchiving can be quite recursive in nature. I understand the hack you posted, but there’s no way I’m going there, sorry ;) > Removing recursion might actually be a better idea. It’ll certainly be > *cleaner* and won’t be processor specific at all. True, but actually very difficult for the object graph in question, bearing in mind it would have to dearchive an existing file correctly. The annoying thing is that it works fine 99% of the time, just hitting the stack limit on rare occasions. —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
