Subject: 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
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?
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)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to maillists@xxxxxxxxx