Re: NSTask, or threading?
Re: NSTask, or threading?
- Subject: Re: NSTask, or threading?
- From: Joseph Kelly <email@hidden>
- Date: Sun, 26 Apr 2009 11:26:00 -0700
You'll most likely want to put your MIDI stuff on a worker thread, and
add synchronization around any data that could possibly be shared
between threads.
http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/Introduction/Introduction.html
It's non-trivial work if you are unfamiliar with concurrency. You will
likely be troubleshooting deadlocks and memory incursions, and timing
related bugs. But there's probably no other way.
Good luck!
Joe K.
On Apr 26, 2009, at 10:39 AM, James Maxwell wrote:
Hello All,
My current project uses something like a database - it's not a
database, but the idea is that it both stores knowledge, and
"searches" its stored knowledge during runtime. I'll call this
database-like entity the "dataThing"... The dataThing is complex -
lots of calculations going on in there.
It's a music app, and the dataThing is listening to input MIDI
events, doing a bunch of processing, then returning something from
its stored knowledge. If all of this happens in the main run loop,
it remains stable, but as the amount of stored knowledge goes up,
and the music gets busier, the playback starts to drag and stutter -
i.e., the amount of work being done in the dataThing is too time
consuming, and the playback starts to suffer.
I tried doing really simple threading of some of the dataThing's
work, using performSelectorInBackground, but that's causes crashes,
apparently arising from objects being freed before their time. I
also tried NSOperation and NSOperationQueue, but that does basically
the same thing. The errors aren't totally consistent - they range
from unexplained exc_bad_access crashes to NSZombie errors about
messaging freed objects, and so on... Anyway, the main point seems
to be that the dataThing really needs to be able to run completely
serially, with it's own data, and yet be allowed to "lag behind" to
a certain degree when the processing gets heavy, without disturbing
playback of the MIDI data. This lagging isn't a huge problem, in
itself, as I can deal with the lag in response time at a later point
in execution (i.e., when I handle the return of the dataThing).
So, how can I put my dataThing into some process, thread, etc., in a
way that keeps it totally in its "own world", so to speak? It seems
like NSTask is the way to go, but perhaps there's also a way to just
create a single, persistent thread for the dataThing to run on...(??)
What I'd like to do is to instantiate my dataThing and run in a
separate process (or similar), then just send it my input MIDI
messages, and listen for its responses. Does that sound like a job
for NSTask? I guess what's not clear to me about NSTask is how to
use it for something that *isn't* already a "program" - everything
I'm finding about NSTask seems to imply that the task is a separate
program (every tutorial seems to be about wrapping command-line
apps). In my case, it will just be a few classes, that process the
input MIDI data in series, and return the result:
MIDI event --> [class 1 -> class 2 -> class 3] -> result
What I want is more like:
MIDI event ------------------> output -------------------------->
integrate result
\ --> [class 1 -> class 2 -> class 3] -> result /
Any tips greatly appreciated. Sorry for the long message...
J.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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 email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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 email@hidden