Oops, sorry, forgot to ask: what happens if the user hits save again while the separate thread is already saving the search indexes to disk? So, there is one save which detaches a thread and starts to write the data to disk, then seconds later the user instigates another save that causes the data to be written to the same path - couldn't this corrupt the data? Sorry for two e-mails. All the best, Keith
--- On Fri, 12/11/09, Ken Thomases <k...@codeweavers.com> wrote: > From: Ken Thomases <k...@codeweavers.com> > Subject: Re: Detaching a thread to save a file? > To: "Keith Blount" <keithblo...@yahoo.com> > Cc: cocoa-dev@lists.apple.com > Date: Friday, December 11, 2009, 11:15 PM > On Dec 11, 2009, at 4:43 PM, Keith > Blount wrote: > > > The problem is that if the project grows in size, > saving this dictionary to disk can take two or three > seconds. For this reason, I would like to save it in the > background, so it doesn’t hold up the interface. According > to Scott Anguish’s Cocoa Programming book, NSThread is > ideal for this sort of thing, and that is what I would like > to do (I’m stuck supporting Tiger, so I need to use > -detachNewThreadSelector:). But I can’t find any obvious > examples of detaching a thread specifically to save a file. > > > > So, my question is - and I already apologised for its > basicness :) - what is the best way to detach a thread for > saving a file, and what issues do I need to be aware of? For > instance, what if the user tries to close the project > (document) while the other thread is saving the file? > > > > Presumably it’s not as simple as using > -detachNewThreadSelector:... to spawn a thread that just > does a simple -writeToFile: method. > > It could very well be that simple. > > The danger with secondary threads is if they may access > data structures that are also accessible from other threads, > especially if one of the threads may be altering the data > structure. > > So, the easiest way to be safe is to have the thread deal > only with data to which it has exclusive access. For > example, if you were going to write an array to file, you > might be tempted to pass to the background thread a > reference to the NSMutableArray ivar that your document > object holds. The problem is that while the background > thread is invoking -writeToFile: on the array, the main > thread is mutating it. One solution is to make a copy > of the array in the main thread and pass the copy to the > background thread. > > With respect to the user closing the document while the > other thread is saving, that depends. From your > description, it seems as though the thread would be writing > a non-essential adjunct file, not the document itself. > In that case, you should be fine. The thread may > continue with its (independent) write operation. > > Cheers, > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
