Re: Processing data maintained with Core Data

Thanks to all for your suggestions.

On 27-Mar-2009, at 18:09, Quincey Morris wrote:
the key question seems to be: what is the thread safety model of your existing code? Generating audio from parameters and file lists held by a different thread seems disaster-prone, so presumably your code doesn't do that, but you also suggest you currently don't have 2 copies of the data, so maybe your code *does* do that.

My code currently doesn't *do* anything. Not on Mac OS. Not yet.

I suppose one could argue that other implementations have two copies of the UI data--one maintained by the UI, with the audio thread retrieving the data it needs at the beginning of its processing loop (ie, a second copy). It's just the second copy isn't 'maintained' per se... it's re-read each time through the audio processing loop.

Based on the information you've provided so far, I'd suggest you snapshot your data model (into a C struct) and pass it off to your background processing thread, where is can be used by your nice, tested C code.

This may be the direction I'll take.

<Just noticed this list replies to sender, not to the list. Duly noted. >
One (hopefully) last thing…

On 28-Mar-2009, at 7:04, Ben Trumbull wrote:
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?

-- P.


Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)

Help/Unsubscribe/Update your Subscription:

This email sent to maillists@xxxxxxxxx