Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
- Subject: Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
- From: Jeffrey Oleander <email@hidden>
- Date: Thu, 09 Feb 2012 19:08:38 -0800 (PST)
> From: Gilles Celli <email@hidden>
> Subject: Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
> To: "Kyle Sluder" <email@hidden>, "Mike Abdullah" <email@hidden>
> Cc: email@hidden
> Date: Thursday, 2012 February 9, 14:23
>
> Thanks for the quick answers!
>
> Yes I'm targeting Mac OS X 10.6 and later so
> canConcurrentlyReadDocumentsOfType: is a welcome addition, I
> completely forgot that.
>
> Strangely if I put the method
> canConcurrentlyReadDocumentsOfType: inside my NSDocument I
> get a warning when trying to open a document (It seems to be
> a QuickLook error ?) on Mac OS X 10.7.3:
>
> [QL] QLError(): +[QLSeamlessDocumentOpener
> seamlessDocumentOpenerForURL:] should only be called in the
> main thread
>
> Now for the cancel question: If I take the more traditional
> approach to cancel the operation inside readFromURL, should
> I fire up a new thread to check the flag's status ?
>
> Gilles
>
>
>> On 2012 Feb 9, at 19:32, Kyle Sluder wrote:
>>> On Thu, 2012 Feb 9 at 08:01, Gilles Celli <email@hidden> wrote:
> >> I searched the mailing-list but didn't find an
> answer….so sorry if this was posted before:
> >>
> >> I've setup a document based application which can
> read large ASCII data files (>150MB).
> >>
> >> When opening the document the method
> readFromURL:ofType:error is used which then opens a small
> feedback window
> >> showing the file name and an animated
> progress bar with a "Cancel" NSButton.
> >
> > If you're targeting Snow Leopard or later, you should
> override
> > +canConcurrentlyReadDocumentsOfType: to return YES.
> That will cause
> > -initWithContentsOfURL:ofType:error: (and therefore
> > -readFromURL:ofType:error:) to execute on a background
> thread.
> >
> > Then you get to the canceling part. The traditional
> approach would be
> > to set a flag when the user clicks Cancel, and
> periodically check this
> > flag from within your -readFromURL:… implementation,
> returning an
> > NSUserCancelledError if you detect it has been set.
> >
> > A more modern approach might be to use
> NSOperationQueue. Instead of a
> > loop, -readFromURL:… would divide its work into
> operations and enqueue
> > those on a queue. Clicking the Cancel button would
> enqueue an
> > operation that would shut down the -readFromURL:'s
> operation queue and
> > cause it to return an NSUserCancelledError.
I don't get it. I though with OS X one of the great
benefits was finally having pre-emptive multi-processing
instead of co-operative multi-processing.
Sure, when the user clicks "Cancel" it's an "event",
it gets stuffed on an event queue, the wheels grind
round and round and eventually that event gets popped
off of the queue and paid attention to. But then...
then the event processor, the action, should see that
it needs to interrupt the file transfer cold,
as close to immediately as possible, the buffers
that were being used for the transfer freed, and
control returned to the regularly scheduled programming.
Neat. Sweet. And at least somewhat close to immediate
in user terms. Not, Eyeore style... "ohhh, maybe...
some... day..., maybe after it gets done filling
the next buffer or 10... we may think about getting
around to doing something about it."
The master, the user, wants it done now!
(Stuff like this gets sooo frustrating when Apple
has the best there is... We love their systems
so much...and yet...)
_______________________________________________
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