What Ken said. Also, it might be more convenient to use NSBlockOperation or -addOperationWithBlock so the function parameters (including the completion handler) are all captured correctly for you automatically. It's a lot more convenient than stashing things in an NSDictionary.
Finally, I misspoke about the application blocking when you defer calling the completion handler. User interaction blocking for async saving doesn't get invoked until much later. As a result, yes the user can continue editing the document, which I suppose is OK since the pending autosave will pick up those changes as well. However, since -autosaveWithImplicitCancellability:… uses -performAsynchronousFileAccessUsingBlock:, any further attempts to gain access to the file will block the main thread, so you'll need to use -continueAsynchronousWorkOnMainQueueUsingBlock: to avoid a potential deadlock when reinvoking the -saveToURL: method on the main queue. Also, what I said about other applications blocking trying to get sole access to the file via file coordination is still true. -KP On Aug 4, 2011, at 7:53 AM, Ken Thomases wrote: > On Aug 4, 2011, at 8:54 AM, Jerry Krinock wrote: > >> I'm getting a crash if I begin some operations and then hit the 'close' >> button on the window while the operations are in progress… >> >> I take the four parameters I receive in >> saveToURL:ofType:forSaveOperation:completionHandler: and put them into a >> dictionary in an NSOperation, and throw this operation onto the end my >> operation queue. (This project was written back in 10.5 so it does not use >> GCD.) > > Did you copy the block, or did you just add it to the dictionary as a value > (which just retains it)? You need to copy it and then later release it. > > >> When this final operation runs, I send this dictionary to a selector on the >> main thread. But the completion handler seems to contain a bomb at this >> point – it usually crashes upon receiving any message, not always in the >> same place. Often, it crashes when I send it to super's >> saveToURL:ofType:forSaveOperation:completionHandler:, which apparently tries >> to copy it, like this… >> >> #0 0x97c68987 in _Block_copy_internal >> #1 0x97c68bd8 in _Block_object_assign >> #2 0x97123a41 in __copy_helper_block_138 >> #3 0x97c67f86 in _Block_call_copy_helper >> #4 0x97c689d3 in _Block_copy_internal >> #5 0x97c68bd8 in _Block_object_assign >> #6 0x9713f43b in __copy_helper_block_40 >> #7 0x97c67f86 in _Block_call_copy_helper >> #8 0x97c689d3 in _Block_copy_internal >> #9 0x9bb22eae in _dispatch_Block_copy >> #10 0x9bb251ea in dispatch_async >> #11 0x9713ac9c in -[NSDocument performAsynchronousFileAccessUsingBlock:] >> #12 0x97123688 in -[NSDocument >> saveToURL:ofType:forSaveOperation:completionHandler:] > > This suggests that you didn't copy it. Thus, the above is the first time it > has been copied, which attempts to relocated it off of its original stack > frame and into the heap. However, that stack frame is long gone and no > longer valid. > > >> Retaining the completionHandler a half dozen times, with no corresponding >> releases, before placing into the dictionary, does not help. So apparently >> it's not memory management. > > Blocks have special memory management requirements and retaining is not > sufficient if the block is to survive its original stack frame. > > Regards, > Ken > > _______________________________________________ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com > > This email sent to kpe...@apple.com _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
