Re: Newbie documentation for MIDI
Re: Newbie documentation for MIDI
- Subject: Re: Newbie documentation for MIDI
- From: Robert Grant <email@hidden>
- Date: Tue, 26 Nov 2002 19:31:09 -0500
I just wanted to say at the end of all this that what I'm doing (with
the NSNotification
stuff) is *working* and sounds like it is usable as long as the
NotificationCenter is not
busy and the Notification handler is not a long running operation. And
I have to say
I like it's KISS nature :-)
It seems to me that with all these options we have lots of tools in our
Cocoa toolbox for
handling these situations. :-)
Robert.
On Tuesday, November 26, 2002, at 06:44 PM, Chris Reed wrote:
Or, duh... read the documentation. :)
" If you pass YES for wait, the current thread blocks until the
perform is completed on the main thread, otherwise the perform is
queued on the main thread and this method returns immediately. "
Maybe if I had just looked at the "waitUntilDone" argument?
As far as internal semaphores and such, it probably uses an NSLock to
protect whatever queue it uses. So it almost certainly is blocking in
that sense. I doubt they wrote it with realtime code in mind.
Cheers
-chris
On Tuesday, November 26, 2002, at 05:22 pm, Chris Reed wrote:
I would guess it's not blocking, since there's no return value.
-chris
On Tuesday, November 26, 2002, at 04:59 pm, Benjamin Golinvaux wrote:
since 10.2, you can use
- (void)performSelectorOnMainThread:(SEL)aSelector
withObject:(id)arg waitUntilDone:(BOOL)wait
in NSObject
That's a wonderfully simple way to schedule a selector to be
executed on the receiver in the main AppKit thread
(the main( ) thread). Passing NO for 'wait' ensures the function
returns immediatly(***)
HTH
Benjamin
(***)However, i do NOT know if this is a blocking call or not. If
someone can give me this info, i'd be very happy.
In order to avoid any trouble, I ended up using a 3rd thread with a
small message queue and use semaphore_signal
(that does not block) in the RT thread and semaphore_wait in that
3rd thread which, in turn, posts messages in the main
thread. Thus blocking or non-blocking was a non-issue for me by
using this "indirection" scheme (unless i've missed
something ;-( )
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.