Re: Newbie documentation for MIDI
Re: Newbie documentation for MIDI
- Subject: Re: Newbie documentation for MIDI
- From: Doug Wyatt <email@hidden>
- Date: Tue, 26 Nov 2002 17:56:23 -0800
On Tuesday, Nov 26, 2002, at 16:26 US/Pacific, Chris Reed wrote:
On Tuesday, November 26, 2002, at 06:07 pm, Kurt Bigler wrote:
on 11/26/02 12:42 PM, Thomas Hudson <email@hidden> wrote:
The approach I used was to use a mach port, which I believe allows
stuffing a message into without blocking (using mach_msg). Then in
the UI thread, an NSPort can monitor this in the runloop. See
NSPort:scheduuleInRunLoop:forMode and NSPort:handleMachMessage.
on 11/26/02 12:36 PM, Michael Thornburgh <email@hidden> wrote:
for cross-thread communication, you're _supposed_ to use <snip>
Any suggestions for how to do this without using objective C?
In that case, I would take a look at CFPort and CFPortMessage. You can
probably use almost exactly the same code as what Michael posted. But
I've never used those CF objects, so I'm not certain.
Let's take a step back ... a little bit of confusion has crept into
this thread.
Either you care about your MIDI input thread never blocking or you
don't.
If you care about the MIDI input thread never blocking, because you
want to always react to something "instantly", or don't trust your
source's timestamps (though you should be able to) and want to take
your own timestamps, then your code should do a finite and small amount
of work in the realtime thread and you must take extra care to not make
calls that may allocate memory -- those calls can and will occasionally
block if the main thread is in the middle of a malloc/free.
But if you don't care about the realtime responsiveness of your MIDI
input thread, you *can* do things that block. The only thing that will
suffer will be your own app's input latencies -- you're not hurting the
system as a whole. Only your app's MIDI input thread will be blocked,
which introduces some minor context-switch overhead, but will not
affect any other processes.
Just *don't* do compute-intensive work in the input thread -- that
happens at realtime priority and *will* block other realtime threads,
system-wide.
The bare-bones way to message between threads is to send a Mach
message. I write directly to Mach when I do this, so I'm not sure
about CFMachPort -- though I suspect it's block-free on the sending
side, if your message is small and you're not filling the port's
message queue (N.B. !!!).
CFMessagePort will always allocate memory on both the sending and
receiving ends of a transaction.
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.