Subject: Re: Processing data maintained with Core Data
Given your existing code base, and RT constraints, I would suggest
you consider pushing changes over to the RT thread in batches.
Basically, update the configuration the RT thread is using in
response to the NSManagedObjectContextDidSaveNotification.
It's sinking in that this might be an even better approach. Is there
any sample code available demonstrating this technique?
No. Worth file a request for at bugreport.apple.com (performance,
enhancements, and features are also "bugs")
Basically, you'll have 2 threads. The main thread for the UI. You
can use Core Data, Cocoa Bindings, etc here, and everything you read
about in the programming guide is relevant. When a
NSManagedObjectContextDidSaveNotification comes through (or the per
event equivalent if you don't want to wait for saving) you'll just
process the userInfo dictionary contents, package them up in a way
that works for your existing code base (typically as collections of
simple value classes like NSString and NSNumber), and enqueue them for
the RT thread to pick up when it's ready.
You'll also have a second background RT thread for the audio
processing. It won't ever touch the UI, it'll just process the
updates enqueued for it by the main thread. The updates will funnel
through your existing code base.
The key concept is to keep the two threads and their worlds isolated
except the for queue of updates. That's the choke point. This is
pretty much always the best way for threads to interact -- at arms
length, through a defined funnel, since it makes MT debugging much
easier (relatively speaking). But it's especially important here as
you'll want to keep the RT thread going without unnecessary
Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)
Please do not post admin requests or moderator comments to the list.
Contact the moderat...
ors at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to maillists@xxxxxxxxx