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 (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 dependencies.

- Ben


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)

Help/Unsubscribe/Update your Subscription:

This email sent to maillists@xxxxxxxxx